Hi,
I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify.
For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message.
However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g.
In OK the Contact header is: Contact: sip:bob@client.biloxi.example.com;transport=tcp
And ACK the R-URI is: ACK sip:bob@client.biloxi.example.com SIP/2.0
Which has got the parameter ‘transport=tcp’ removed – why is this?
In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail.
Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much!
Yufei
Hello, I think it is possible to choose wrong transport type to relay . so i prefer that add transport parameter to Route headers. Kamailio handles it with loose_route function and mhomed feature.
Yasin CANER
F14 200 OK Proxy 1 -> Alice
SIP/2.0 200 OK
Contact: sip:bob@client.biloxi.example.com;transport=tcp
..............
F15 ACK Alice -> Proxy 1
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76 Max-Forwards: 70 Route: sip:ss1.atlanta.example.com;lr, sip:ss2.biloxi.example.com;lr From: Alice sip:alice@atlanta.example.com;tag=9fxced76sl To: Bob sip:bob@biloxi.example.com;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
F16 ACK Proxy 1 -> Proxy 2
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76 ;received=192.0.2.101 Max-Forwards: 69 Route: sip:ss2.biloxi.example.com;lr From: Alice sip:alice@atlanta.example.com;tag=9fxced76sl To: Bob sip:bob@biloxi.example.com;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Yufei Tao yufei.tao@gmail.com Sent: Sunday, April 28, 2019 11:54 PM To: Kamailio (SER) - Users Mailing List Subject: [SR-Users] SIP basic flow question: R-URI in ACK
Hi,
I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify.
For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message.
However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g.
In OK the Contact header is:
Contact: sip:bob@client.biloxi.example.com;transport=tcp
And ACK the R-URI is:
ACK sip:bob@client.biloxi.example.com SIP/2.0
Which has got the parameter ‘transport=tcp’ removed – why is this?
In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail.
Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much!
Yufei
Hello,
there is an errata for that RFC, but it refers only to the BYE, where it adds back the transport=tcp, but the ACK R-URI should follow the same rules, see:
* https://www.rfc-editor.org/errata/eid5294
Cheers, Daniel
On 28.04.19 22:54, Yufei Tao wrote:
Hi,
I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify.
For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message.
However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g.
In OK the Contact header is:
Contact: sip:bob@client.biloxi.example.com;transport=tcp
And ACK the R-URI is:
ACK sip:bob@client.biloxi.example.com SIP/2.0
Which has got the parameter ‘transport=tcp’ removed – why is this?
In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail.
Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much!
Yufei
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
YASIN CANER -
Yufei Tao