Hello, I am not sure what variant you want to advocate with this message/excerpt from RFC, but it is about "forwarded response to a **request that contains a To tag**", and the request (the initial INVITE) has no To tag.
For replies corresponding to requests within dialog, the to-tag has to be preserved and I think kamailio does it even if it has to generate a reply (e.g., timeout on re-INVITE routing). Cheers, Daniel On 23.07.20 14:53, Henning Westerholt wrote: > > Hello, > > > > just to add to the RFC quoted below: this is referring to 1xx or 2xx > responses. But later on, in the section, the RFC seems to be quite clear: > > > > If the only > > response that was received is a 503, the proxy SHOULD generate > > a 500 response and forward that upstream. > > > > A proxy MUST NOT modify the To tag in any forwarded response to > > a request that contains a To tag. > > > > Cheers, > > > > Henning > > > > *From:*sr-users <[email protected]> *On Behalf Of > *Gerry | Rigatta > *Sent:* Thursday, July 23, 2020 2:41 PM > *To:* [email protected] > *Cc:* Kamailio (SER) - Users Mailing List <[email protected]> > *Subject:* Re: [SR-Users] bug ? remap_503_500 breaks dialogs > > > > Hi Daniel, > > > > thanks for looking into this. > > > > The initial INVITE does not have a to-tag but there is an intermediate > session progress with a to-tag. See grep below. > > > > The RFC does not distinguish between established or provisional > dialogs when it comes to the handling of the to-tags. If there is a > to-tag it must not be changed by the Proxy. Clearly that must be so > because the to-tag is used by the UAC to identify the call. > > > > Best Gerry > > > > > > IP addresses are changed in below dialog for security reasons > > > > U 7.7.23.109:5060 -> 11.22.17.24:5060 #5 > > INVITE sip:[email protected]:5060 > <sip:[email protected]:5060> SIP/2.0..Max-Forwards: 19. > > .P-Asserted-Identity: tel:+4867777777..Via: <tel:+4867777777..Via:> > SIP/2.0/UDP 7.7.23.109:5060 > > ;rport;branch=z9hG4bK1682611991..From: "004867777777" > <sip:004867777777@7 > > 8.47.203.109>;tag=540342132..To: <sip:[email protected]:5060 > > >..Call-ID: [email protected] > <mailto:[email protected]>..CSeq: 1 INVITE..User-Agent: nulltech. > > .Contact: <sip:[email protected]:5060>..Allow: ACK, INVITE, BYE, > > CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported: > 100rel..Content-T > > ype: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 > 1595505 > > 273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23.109..t=0 0..m=audi > > o 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 > PCMU/8000..a=rtpm > > ap:101 telephone-event/8000.. > > > # > > U 11.22.17.24:5060 -> 7.7.23.109:5060 #6 > > SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP > 78.47. > > 203.109:5060;rport=5061;branch=z9hG4bK1682611991;received=7.7.23.109..Fr > > om: "004867777777" <sip:[email protected]>;tag=540342132..To: <s > > ip:[email protected] > <mailto:[email protected]>:5060>..Call-ID: > [email protected] <mailto:[email protected]> > > 9..CSeq: 1 INVITE..Server: kamailio (5.2.3 > (x86_64/linux))..Content-Length: > > 0.... > > > # > > U 11.22.17.24:5060 -> 13.23.9.94:5060 #7 > > INVITE sip:[email protected]:5060 > <sip:[email protected]:5060> SIP/2.0..Record-Route: <si > > p:11.22.17.24:5060;lr=on>..Max-Forwards: 18..P-Asserted-Identity: tel:+ > > 4867777777..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37 > > b7feb047b6707c5fb8a298d36fc.0..Via: SIP/2.0/UDP 7.7.23.109:5060;received > > =7.7.23.109;rport=5061;branch=z9hG4bK1682611991..From: "004867777777" < > > sip:[email protected] > <sip:[email protected]>>;tag=540342132..To: <sip:111100791456321475 > > @13.23.9.94:5060>..Call-ID: [email protected] > <mailto:[email protected]>..CSeq: 1 INVITE..Us > > er-Agent: nulltech..Contact: <sip:[email protected]:5060>..Allow: > > ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, > INFO..Supported > > : 100rel..Content-Type: application/sdp..Content-Length: > 209....v=0..o=yate > > 1595505273 1595505273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23 > > .109..t=0 0..m=audio 28610 RTP/AVP 8 0 101..a=rtpmap:8 > PCMA/8000..a=rtpmap: > > 0 PCMU/8000..a=rtpmap:101 telephone-event/8000.. > > > # > > U 13.23.9.94:5060 -> 11.22.17.24:5060 #8 > > SIP/2.0 100 Trying..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d > > 4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Via: SIP/2.0 > > /UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=z9hG4bK168 > > 2611991..Record-Route: <sip:11.22.17.24:5060;lr=on>..From: "00371673360 > > 58" <sip:[email protected]>;tag=540342132..To: <sip:1111007914563 > > [email protected] <mailto:[email protected]>:5060>..Call-ID: > [email protected] <mailto:[email protected]>..CSeq: 1 INVIT > > E..User-Agent: Ravetel SIP proxy..Allow: INVITE, ACK, CANCEL, > OPTIONS, BYE, > > REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: > <sip:1111007 > > [email protected] > <mailto:[email protected]>:5060>..Content-Length: 0.... > > > # > > U 13.23.9.94:5060 -> 11.22.17.24:5060 #9 > > SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 11.22.17.24:5060;branch= > > z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Vi > > a: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch= > > z9hG4bK1682611991..Record-Route: <sip:11.22.17.24:5060;lr=on>..From: "0 > > 04867777777" <sip:[email protected]>;tag=540342132..To: <sip:103 > > [email protected] > <mailto:[email protected]>:5060>;tag=as6d86b4e8..Call-ID: > 1279305029@78. > > 47.203.109..CSeq: 1 INVITE..User-Agent: Ravetel SIP proxy..Allow: > INVITE, A > > CK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: > replac > > es..Contact: <sip:[email protected]:5060>..Content-Type: app > > lication/sdp..Content-Length: 235....v=0..o=root 714 714 IN IP4 > 136.243.29. > > 94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101 > > ..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 > telephone-event/ > > 8000..a=fmtp:101 0-16..a=ptime:20..a=sendrecv.. > > > # > > U 11.22.17.24:5060 -> 7.7.23.109:5060 #10 > > SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 7.7.23.109:5060;received= > > 7.7.23.109;rport=5061;branch=z9hG4bK1682611991..Record-Route: <sip:116.2 > > 02.187.204:5060;lr=on>..From: "004867777777" <sip:[email protected]. > > 109>;tag=540342132..To: <sip:[email protected]:5060>;tag=as6 > > d86b4e8..Call-ID: [email protected] > <mailto:[email protected]>..CSeq: 1 INVITE..User-Agent: Ravet > > el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, > > NOTIFY, INFO..Supported: replaces..Contact: > <sip:[email protected] > > 3.29.94:5060>..Content-Type: application/sdp..Content-Length: > 235....v=0..o > > =root 714 714 IN IP4 13.23.9.94..s=session..c=IN IP4 13.23.9.94..t=0 > > 0..m=audio 10454 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 > PCMU/800 > > 0..a=rtpmap:101 telephone-event/8000..a=fmtp:101 > 0-16..a=ptime:20..a=sendre > > cv.. > > > # > > > > U 13.23.9.94:5060 -> 11.22.17.24:5060 #39 > > SIP/2.0 503 Service Unavailable..Via: SIP/2.0/UDP 11.22.17.24:5060;bran > > ch=z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24. > > .Via: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;bran > > ch=z9hG4bK1682611991..From: "004867777777" <sip:[email protected] > > 9>;tag=540342132..To: <sip:[email protected]:5060>;tag=as6d8 > > 6b4e8..Call-ID: [email protected] > <mailto:[email protected]>..CSeq: 1 INVITE..User-Agent: Ravet > > el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, > SUBSCRIBE, N > > OTIFY, INFO..Supported: replaces..X-Asterisk-HangupCause: Call > Rejected..X- > > Asterisk-HangupCauseCode: 21..Content-Length: 0.... > > > # > > U 11.22.17.24:5060 -> 13.23.9.94:5060 #40 > > ACK sip:[email protected]:5060 > <sip:[email protected]:5060> SIP/2.0..Max-Forwards: 18..Vi > > a: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37b7feb047b6707c5 > > fb8a298d36fc.0..From: "004867777777" <sip:[email protected]>;tag > > =540342132..To: <sip:[email protected]:5060>;tag=as6d86b4e8. > > .Call-ID: [email protected] > <mailto:[email protected]>..CSeq: 1 ACK..Content-Length: 0.... > > # > > U 11.22.17.24:5060 -> 7.7.23.109:5060 #41 > > SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= > > 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" > > <sip:[email protected]>;tag=540342132..To: <sip:1111007914563214 > > [email protected] > <mailto:[email protected]>:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: > > > [email protected] <mailto:[email protected]>..CSeq: 1 > INVITE..Server: kamailio (5.2.3 (x86_64/l > > inux))..Content-Length: 0.... > > > # > > U 11.22.17.24:5060 -> 7.7.23.109:5060 #42 > > SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= > > 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" > > <sip:[email protected]>;tag=540342132..To: <sip:1111007914563214 > > [email protected] > <mailto:[email protected]>:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: > > > [email protected] <mailto:[email protected]>..CSeq: 1 > INVITE..Server: kamailio (5.2.3 (x86_64/l > > inux))..Content-Length: 0.... > > > # > > > > > > On 23 Jul 2020, at 10:51, Daniel-Constantin Mierla > <[email protected] <mailto:[email protected]>> wrote: > > > > Did the initial INVITE received the 200ok, the call is connected > and this is the case of a re-INVITE? In such case the dialog has > to be terminated by a BYE. > > If the call is not established, so it is between initial INVITE > and no 200ok was received, then the INVITE request did not contain > the To-tag. And what is done by Kamailio is valid as per email > responses so far. > > Maybe you can just send the ngrep output with all sip > requests/replies for this case and we can see exactly which > scenario you talk about. > > Cheers, > Daniel > > On 23.07.20 09:41, Gerry | Rigatta wrote: > > Indeed, at this stage there is no dialog established and > there can be many To-tags in 1xx provisional responses > (eg, a parallel forking scenario) -- the to-tag of the > dialog has to be taken from 200ok. > > As far as I read this is not correct. Also a provisional > dialog is a dialog according to RFC3261. Only in the case that > the request did not contain a to-tag the provisional messages > may insert their own to-tags: > > > > "1xx and 2xx responses may be involved in the establishment of > > dialogs. When a request does not contain a To tag, the To > tag > > in the response is used by the UAC to distinguish multiple > > responses to a dialog creating request. A proxy MUST NOT > > insert a tag into the To header field of a 1xx or 2xx > response > > if the request did not contain one. A proxy MUST NOT modify > > the tag in the To header field of a 1xx or 2xx response.” > > https://tools.ietf.org/html/rfc3261#page-111 > > > > In any case, this bug is not a about provisional messages. The > 500 message terminates the dialog for the UAC (yate) and the > UAC needs to be able to identify it. An UAC identifies the > dialog by the call-id, local tag and remote tag. > > > > > 12 > <https://tools.ietf.org/html/rfc3261#section-12> > Dialogs > > > A dialog is identified at each UA with a > dialog ID, which consists of a Call-ID value, > a local tag and a remote tag…" > > > > > > On 23 Jul 2020, at 10:07, Daniel-Constantin Mierla > <[email protected] <mailto:[email protected]>> wrote: > > > > Indeed, at this stage there is no dialog established and > there can be many To-tags in 1xx provisional responses > (eg, a parallel forking scenario) -- the to-tag of the > dialog has to be taken from 200ok. > > This parameter is probably to have a shortcut of doing: > > failure_route[REMAP503] { > > if(t_check_status("503")) { > > t_reply("500", "Server error"); > exit; > > } > > Being like the server application is generating the 500 > (so using own tag), instead of forwarding the 503. Not a > bug, but if anyone is willing to add an option to allow > re-using the to-tag from received reply, I am fine with it. > > Anyhow, even if this would be fixed, I am wondering how > yate is going to work in parallel/serial forking scenarios > where different to-tags flow for a while and the final > failure response can have any to-tag, including a new one > (e.g., from a device not sending any 1xx or again from > kamailio (e.g., when last target doesn't reply at all)). > > Cheers, > Daniel > > On 23.07.20 06:08, M S wrote: > > The SIP code 503 is tricky in the sense that i can > indicate either server maintenance or server overload. > In both cases it can send Retry-After header and any > subsequent requests from same source are ignored for > the duration of Retry-After interval. [1]. > > > > Additionally RFC3261 and RFC3263 define that transport > failures (generally due to fatal ICMP errors in UDP > and connection failures in TCP) should be treated as > 503 response. [2]. > > > > So in all above cases, it is most likely that dialog > does not establishes at all and 503 response is > treated similar to stateless response. Therefore, a > to-tag can be added/replaced before sending it to UAC. > > > > Theoretically, kamailio should check and use to-tag > from 503 response when converting it to 500 response > and only create new to-tag if it is absent. > > > > References: > > > > [1] https://tools.ietf.org/html/rfc3261#section-21.5.4 > > > > [2] > > https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4 > > > > > > Hope this helps. > > > > > > > > On Wed, 22 Jul 2020 at 21:08, Henning Westerholt > <[email protected] <mailto:[email protected]>> wrote: > > Hello, > > > > Apparently, this is the way the code works: > > > > t_reply.c: > > if (relayed_code==503 && > tm_remap_503_500){ > > /* replace a final > 503 with a 500: > > * generate a > "FAKE" reply and a new to_tag (for easier > > * debugging)*/ > > > > Lets see if maybe others can comment as well. > Otherwise you could just open an issue on our > tracker, it is probably not that hard to change this. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > <https://gilawa.com/> > > > > *From:* sr-users > <[email protected] > <mailto:[email protected]>> *On > Behalf Of *Gerry | Rigatta > *Sent:* Wednesday, July 22, 2020 8:58 PM > *To:* Kamailio (SER) - Users Mailing List > <[email protected] > <mailto:[email protected]>> > *Subject:* [SR-Users] bug ? remap_503_500 breaks > dialogs > > > > Hi, > > > > I am using Kamailio 5.2. > > > > Apparently the remapping of 503 to 500 codes in > the tm module does also change the to-tag. This > behaviour breaks dialogs with yate and therefore > calls hang and the 503 remains unacknowledged. > After disabling the 503 to 500 remapping with > modparam("tm", "remap_503_500", 0) all works fine > again. > > > > Changing the to-tag in a dialog seems to > contradict RFC3261, or do I see this wrongly? > > > 12 > > <https://tools.ietf.org/html/rfc3261#section-12>Dialogs > > > A dialog is identified at each UA with a > dialog ID, which consists of a Call-ID value, > a local tag and a remote tag…" > > > > Thanks for looking into this. > > > > Gerry > > > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > <mailto:[email protected]> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > <mailto:[email protected]> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > > Daniel-Constantin Mierla -- www.asipto.com > <http://www.asipto.com/> > > www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > > Funding: https://www.paypal.me/dcmierla > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > <mailto:[email protected]> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > > Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/> > > www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > > Funding: https://www.paypal.me/dcmierla > > > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
