HI
I am trying to do the early media like this:
PSTN/GW1 -> Kamailio -> Asterisk
--> PSTN/GW2
GW1 send invite to Kamilio, Kamilio proxy to Asterisk,
Asterisk reply with 183 ( with to tag=A) and sdp
After the playing some medium, asterisk send 603 reply to Kamailio
Kamilio intercept the 603, and lookup the routing table, decide to send invite to GW2.
GW2 reply with 180/200OK with to tag=B
In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A.
Is it the right way to do? If so how to change the to tag?
or do I need B2BUA ( only signalling) to do the early media?
thanks.
min
There is no need to change the tag. GW1 must accept the 200 OK with different tag, otherwise the gateway is buggy.
If the gateway is really buggy, the usual workaround is to strip the to-tag from the provisional responses, i.e. remove the to-tag from Asterisk's 183 response, e.g. using functions from textops module.
regards Klaus
On 28.03.2012 02:27, Min Wang wrote:
HI
I am trying to do the early media like this:
PSTN/GW1 -> Kamailio -> Asterisk
--> PSTN/GW2
GW1 send invite to Kamilio, Kamilio proxy to Asterisk,
Asterisk reply with 183 ( with to tag=A) and sdp
After the playing some medium, asterisk send 603 reply to Kamailio
Kamilio intercept the 603, and lookup the routing table, decide to send invite to GW2.
GW2 reply with 180/200OK with to tag=B
In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A.
Is it the right way to do? If so how to change the to tag?
or do I need B2BUA ( only signalling) to do the early media?
thanks.
min
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2012/3/28 Min Wang ser.basis@gmail.com:
In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A.
Totally wrong. Multiple (early-)dialogs are 100% valid according to RFC 3261. If you find some SIP device failing when it receives multiple 180/183/200 responses with different To-tag, then drop it
Hi Kluas and Iñaki:
Thank you a lot for the information!
min
On 03/28/2012 12:37 PM, Iñaki Baz Castillo wrote:
2012/3/28 Min Wangser.basis@gmail.com:
In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A.
Totally wrong. Multiple (early-)dialogs are 100% valid according to RFC 3261. If you find some SIP device failing when it receives multiple 180/183/200 responses with different To-tag, then drop it
Hi,
On 03/28/2012 06:37 PM, Iñaki Baz Castillo wrote:
2012/3/28 Min Wang ser.basis@gmail.com:
In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A.
Totally wrong. Multiple (early-)dialogs are 100% valid according to RFC 3261. If you find some SIP device failing when it receives multiple 180/183/200 responses with different To-tag, then drop it
I recently learned that for example Siemens switches implement "Request Disposition: no-fork" defined in http://www.ietf.org/rfc/rfc3841.txt, and if for some reason you decide to fork nonetheless on your side, you'd probably want to do something about the different to-tags (although you're violating against that specific RFC then). No idea how such a device would react to not getting a to-tag at all by stripping it out as Klaus suggested in another response, but at least that Siemens switch doesn't bail out on getting different to-tags in provisional replies.
Andreas
Hello,
On 3/29/12 1:14 AM, Andreas Granig wrote:
Hi,
On 03/28/2012 06:37 PM, Iñaki Baz Castillo wrote:
2012/3/28 Min Wangser.basis@gmail.com:
In order to properly proxy the msg to GW1, Kamailio seems need to change the to tag from B to A.
Totally wrong. Multiple (early-)dialogs are 100% valid according to RFC 3261. If you find some SIP device failing when it receives multiple 180/183/200 responses with different To-tag, then drop it
I recently learned that for example Siemens switches implement "Request Disposition: no-fork" defined in http://www.ietf.org/rfc/rfc3841.txt, and if for some reason you decide to fork nonetheless on your side, you'd probably want to do something about the different to-tags (although you're violating against that specific RFC then). No idea how such a device would react to not getting a to-tag at all by stripping it out as Klaus suggested in another response, but at least that Siemens switch doesn't bail out on getting different to-tags in provisional replies.
I fully agree that devices not supporting multiple to-tags in provisional replies should be dropped, it will make life easier for everyone.
Regarding hacks to make an workaround, in many cases I saw devices requiring to-tag in 183. In that case, a solution can be dropping 183 from reply route and send 180 instead with t_reply(...).
Cheers, Daniel
2012/3/29 Andreas Granig agranig@sipwise.com:
I recently learned that for example Siemens switches implement "Request Disposition: no-fork" defined in http://www.ietf.org/rfc/rfc3841.txt,
Annoying spec. Now the client can tell the proxy "please don't fork"... WTF?
-
Andreas Granig -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Min Wang