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/2.0..Max-Forwards: 19. .P-Asserted-Identity: 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]: 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]:5060>..Call-ID: [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/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]>;tag=540342132..To: <sip:111100791456321475 @13.23.9.94:5060>..Call-ID: [email protected]: 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]:5060>..Call-ID: [email protected]: 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]: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]: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]: 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]: 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/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]: 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]:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: [email protected]: 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]:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: [email protected]: 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]> 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 >> <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 >>>> <https://tools.ietf.org/html/rfc3261#section-21.5.4> >>>> >>>> [2] https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4 >>>> <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/ <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 >>>> <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 >>>> <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 >>> <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 >>> <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 <https://www.paypal.me/dcmierla>
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
