Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
SIP message parsing bug RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    There seems to be an error in MSS's SIP message parsing.  Here's an INVITE that was sent to MSS. 

     

    INVITE sip:+18005551212@server:3938 SIP/2.0
    Record-Route: <sipTongue Tiederver>;lr
    Record-Route: <sip:4.79.212.236;lr;ftag=VPSF506071629460>
    Record-Route: <sip:4.79.212.229;lr;ftag=VPSF506071629460>
    Via: SIP/2.0/TCP server:5060;branch=z9hG4bKd3c9815b1b826f88822a085f86a728e1
    Via: SIP/2.0/UDP 4.79.212.236;branch=z9hG4bK29df.9f62945.0
    Via: SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK29df.8e23e29.0
    Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1178612752487
    From: <sip:+18005551212@4.68.250.148>;tag=VPSF506071629460
    To: <sip:+18005551212@4.79.212.229:5060>
    Call-ID: PHXMGC0120070514172645012149@209.244.63.36
    CSeq: 1 INVITE
    Contact: <sip:+18005551212@4.68.250.148:5060;transport=udp>
    Max-Forwards: 69
    Content-Type: application/sdp
    Content-Length: 164
    Remote-Party-ID: <sip:+18005551212@4.68.250.148>;privacy=off;screen=yes;party=calling
    Allow: INVITE,CANCEL,BYE,ACK,REFER

     

     

    And here's a response from MSS.  Note the Record-Route header:

     

    SIP/2.0 200 OK
    FROM: <sip:+18005551212@4.68.250.148>;tag=VPSF506071629460
    TO: <sip:+18005551212@4.79.212.229:5060>;tag=d713e1598f;epid=84E441DDC0
    CSEQ: 1 INVITE
    CALL-ID: PHXMGC0120070514172645012149@209.244.63.36
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP server:5060;branch=z9hG4bKd3c9815b1b826f88822a085f86a728e1
    VIA: SIP/2.0/UDP 4.79.212.236;branch=z9hG4bK29df.9f62945.0
    VIA: SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK29df.8e23e29.0
    VIA: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1178612752487
    RECORD-ROUTE: <sipTongue Tiederver>;ftag=VPSF506071629460>;lr;lr,<sip:4.79.212.236
    CONTACT: <sipTongue Tiederver:3938;transport=Tcp;maddr=10.0.0.99>;automata
    CONTENT-LENGTH: 186
    CONTENT-TYPE: application/sdp
    ALLOW: INVITE,CANCEL,BYE,ACK,REFER
    SERVER: RTCC/3.0.0.0
    ALLOW: Ack, Cancel, Bye,Invite,Message,Info,Service,Options,BeNotify

     

     

    The Record-Route headers are being incorrectly parsed.  The correct Route headers are not being put in the message. Because of this, the responses are never reaching the correct place and the call is never getting established.

    Monday, May 14, 2007 5:55 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    It looks like the problem might be this line in the INVITE:

     

    Record-Route: <sipTongue Tiederver>;lr

     

    I think the lr parameter ought to be inside the <>, rather than outside - i.e., a parameter on the URI, rather than on the field.

     

    That said, better error handling on our part here might be a good thing.  And thanks for the the note about resending the OK if it isn't ACK'd.  We actually get our SIP stack from another team, so I'll pass your report along for them to look at.

    Friday, June 1, 2007 12:57 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    I also noticed that when this happened, MSS was NOT resending the 200 response.  There was no ACK to the 200 response (because the correct Route headers were not present), but MSS was not retransmitting the 200 OK.

     

    "Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP.  To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable."

     

    - RFC 3261, Page 85

    Monday, May 14, 2007 8:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It looks like the problem might be this line in the INVITE:

     

    Record-Route: <sipTongue Tiederver>;lr

     

    I think the lr parameter ought to be inside the <>, rather than outside - i.e., a parameter on the URI, rather than on the field.

     

    That said, better error handling on our part here might be a good thing.  And thanks for the the note about resending the OK if it isn't ACK'd.  We actually get our SIP stack from another team, so I'll pass your report along for them to look at.

    Friday, June 1, 2007 12:57 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yeah, I think you're right about the "lr".  It should be outside of the angle brackets. 

     

    But the SIP spec says that if there are angle brackets around a URI, the whole thing is treated as the URI.  So I think the parsing should take that into consideration.

     

    Ideally, the "lr" would be done correctly anyway, but that's out of my control.  That SIP message came from our SIP provider. 

    Friday, June 1, 2007 5:42 PM