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
