Answered by:
SIP message parsing bug

Question
-
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: <siperver>;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,REFERAnd 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: <siperver>;ftag=VPSF506071629460>;lr;lr,<sip:4.79.212.236
CONTACT: <siperver: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,BeNotifyThe 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
-
It looks like the problem might be this line in the INVITE:
Record-Route: <sip
erver>;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
-
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 -
It looks like the problem might be this line in the INVITE:
Record-Route: <sip
erver>;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 -
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