Thank you Brett. We use lr=on because of some broken user agents which don't like the proper 'lr'.
On 27 August 2015 at 21:14, Brett Tate <br...@broadsoft.com> wrote: > Hi, > > Another issue is that your Record-Route sip-uri used "lr=on" instead of > "lr". RFC 3261 defines lr-param without a value. > > RFC 3261 section 16.12.1 has some loose routing and strict routing > examples which may be of interest. > > > > -----Original Message----- > > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > > implementors-boun...@lists.cs.columbia.edu] On Behalf Of David > Cunningham > > Sent: Sunday, August 23, 2015 8:27 PM > > To: Joegen Baclor > > Cc: sip-implementors@lists.cs.columbia.edu > > Subject: Re: [Sip-implementors] R-URI on ACK > > > > Thank you for the explanation Joegen and apologies for my mixed > terminology. > > > > The IP aa.aa.13.240 is our address so I wouldn't expect it to be on the > route > > going out. > > > > I think I have been misunderstanding loose routes. I had presumed they > meant > > the R-URI didn't change at all. > > > > > > On 22 August 2015 at 11:25, Joegen Baclor <jbac...@ezuce.com> wrote: > > > > > They are correct. ACK for 200 Ok follows the rules for requests > > > within a dialog. Your ACK request-uri should point to the value of > > > the Contact-URI sent in the 200 Ok. > > > > > > >> a) Should the R-URI be changed on a reply? (as opposed to a new > > > >> dialog) > > > Not sure what you mean by "R-URI on a reply" . ACKs are requests. > > > Responses do not have request-uris. > > > > > > b) Doesn't the loose routing (lr in the record-route for > > > bb.bb.224.202) > > >>> mean that the R-URI shouldn't be changed anyway? > > >>> > > >> No. The record-route or route-sets are the hops that your request > > >> would > > > follow. You ACK should have been contructed as follows > > > > > > ACK sip:+11234567...@cc.cc.13.45:5060 SIP/2.0 > > > Route: <sip:aa.aa.13.240:5060;lr=on> > > > Route: <sip:bb.bb.224.202:5060;lr;ftag=as1514f3e7> > > > > > > Take note that there were two record routes in the 200 OK. Your > > > implementation must insert those two in the ACK. Your ACK appears to > > > only insert the top-most route. You, therefore, have two violations > here. > > > Request-URI is wrong and Route-set is wrong. > > > > > > Joegen > > > > > > > > > > > > > > > On 08/22/2015 09:01 AM, David Cunningham wrote: > > > > > >> Hello, > > >> > > >> I'm looking for some advice on a response from a SIP termination > provider. > > >> They send us the 200 OK below, and we send them the ACK. > > >> > > >> They say that our ACK is invalid because it's R-URI should contain > > >> "+11234567...@cc.cc.13.45:5060" rather than > > >> "+11234567...@bb.bb.224.202 :5060". > > >> Presumably they say that because what they want is in the Contact > > >> header in their 200 OK. > > >> > > >> My questions are: > > >> a) Should the R-URI be changed on a reply? (as opposed to a new > > >> dialog) > > >> b) Doesn't the loose routing (lr in the record-route for > > >> bb.bb.224.202) mean that the R-URI shouldn't be changed anyway? > > >> > > >> Thanks in advance for any help. > > >> > > >> > > >> Received from provider address bb.bb.224.202: > > >> > > >> SIP/2.0 200 OK. > > >> Via: SIP/2.0/UDP > > >> aa.aa.13.240;branch=z9hG4bK02ee.83d31f591682ebd45da194d341fa23f9.0. > > >> Via: SIP/2.0/UDP aa.aa.13.195:5060;rport=5060;branch=z9hG4bK4bcb23fc. > > >> From: <sip:+12345678...@aa.aa.13.195>;tag=as1514f3e7. > > >> To: <sip:+11234567...@ot.provider.com:5060>;tag=gK00d4fe47. > > >> Call-ID: xxx. > > >> CSeq: 102 INVITE. > > >> Record-Route: <sip:bb.bb.224.202:5060;lr;ftag=as1514f3e7>. > > >> Record-Route: <sip:aa.aa.13.240:5060;lr=on>. > > >> Accept: application/sdp. > > >> Contact: <sip:+11234567...@cc.cc.13.45:5060>. > > >> Allow: INVITE,ACK,CANCEL,BYE,PRACK,OPTIONS. > > >> Content-Length: 244. > > >> Content-Disposition: session; handling=required. > > >> Content-Type: application/sdp. > > >> . > > >> v=0. > > >> o=Sonus_UAC 188128247 152711770 IN IP4 cc.cc.13.45. > > >> s=SIP Media Capabilities. > > >> c=IN IP4 cc.cc.13.72. > > >> t=0 0. > > >> m=audio 43276 RTP/AVP 0 101. > > >> a=rtpmap:0 PCMU/8000. > > >> a=rtpmap:101 telephone-event/8000. > > >> a=fmtp:101 0-15. > > >> a=sendrecv. > > >> a=maxptime:20. > > >> > > >> > > >> Sent to provider address bb.bb.224.202: > > >> > > >> ACK sip:+11234567...@bb.bb.224.202:5060 > > >> Via: SIP/2.0/UDP > > >> aa.aa.13.240;branch=z9hG4bKa205.5b9b58c0e9cb82ab7edf866d7b03a805.0 > > >> Via: SIP/2.0/UDP aa.aa.13.194:5060;rport=5060;branch=z9hG4bK45d24b48 > > >> Route: <sip:bb.bb.224.202:5060;lr;ftag=as2e95ab82> > > >> Max-Forwards: 69 > > >> From: <sip:+12345678...@aa.aa.13.194>;tag=as2e95ab82 > > >> To: <sip:+11234567...@ot.provider.com:5060>;tag=gK08a9c7fd > > >> Contact: <sip:+12345678...@aa.aa.13.194:5060> > > >> Call-ID: xxx > > >> CSeq: 102 ACK > > >> User-Agent: XXX > > >> Content-Length: 0 > -- David Cunningham, Voisonics http://voisonics.com/ USA: +1 213 221 1092 UK: +44 (0) 20 3298 1642 Australia: +61 (0) 2 8063 9019 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
