ok, but how do you think a b2bua should handle this? modify the
originator in all the replies to match the one of the first reply?
o Iñaki Baz Castillo [11/28/08 14:01]:
Hi, I'm testing SEMS and Sippy B2BUA as transparent B2BUA. I've discovereed
the same bug in both so I copy&paste the same report I've already done in the
other project (and replace Sippy B2BUA with SEMS).
-----------------------
I've realized that SEMS as B2BUA has an issue when handling parallel
responses. Basically, SEMS receives different provisional responses in leg_B
(different To_tag) but convert all of them to the same To_tag in leg_A.
This is an error in case the responses are 183 containing an SDP because if a
UAC (the caller) receives a provisional 183 response (To_tag=AAA) with an
SDP=AAA, and later receives a 200 OK with same To_tag=AAA but different
SPD=BBB, then it should use SDP=AAA and ignore SDP=BBB.
This is: the SDP cannot be changed during a dialog (note that there is just
*one* dialog between the caller and SEMS since SEMS already sent one
To_tag).
So I describe the current behaviour and the problem it originates:
- X-Lite calls SEMS.
- SEMS calls to [EMAIL PROTECTED]
- A PROXY receives the INVITE and does parallel forking (to alice and bob).
- Both alice and bob replies 183 to the PROXY:
- alice 183:
- To_tag = alice_to_tag
- SDP = alice_sdp
- bob 183:
- To_tag = bob_to_tag
- SDP = bob_sdp
- PROXY forwards the replies to SEMS.
- SEMS generates two 183 to X-Lite:
- alice_leg_A 183:
- To_tag = leg_A_to_tag
- SDP = alice_sdp <--- The original of course
- bob_leg_A 183:
- To_tag = leg_A_to_tag <--- The same !!!!!
- SDP = bob_sdp <--- The original of course
(note that both 183 has same To_tag but different SDP).
- alice_leg_A 183 arrives before so X-Lite starts receiving (and rendering to
the human) the SDP of alice (alice_sdp).
- Later X-Lite receives bob_leg_B 183, with same To_tag but **different SDP=
bob_sdp**. This is wrong, the SDP cannot change during an dialog. Note that
there is just **one** dialog (early-dialog in fact) between X-Lite and SEMS
since SEMS has replied just **one** To_tag.
So X-Lite just ignores this new 183 with "wrong" SDP.
- In leg B world, bob finally answers the calls so sends a 200 OK. The PROXY
sends this 200 OK to SEMS, so SEMS receives:
- bob 200:
- To_tag = bob_to_tag
- SDP = bob_sdp
- Now SEMS generates the following 200 to X-Lite:
- bob_leg_A 200:
- To_tag = leg_A_to_tag
- SDP = bob_sdp
- When X-Lite receives this 200 it must ignore the SDP (bob_sdp) since X-Lite
already received an SDP in this *same* early-dialog (alice_sdp in the first
183 from SEMS). This new SDP in the same early-dialog must, even if
different, be ignored, so X-Lite sends RTP to alice instead of bob, and also
expects receiving RTP from alice instead of bob.
This is obviously wrong and I can sure that my report is valid (it is
something I've already dealed with in other cases).
I paste a simple SIP flow that shows the problem (they are 180 instead of 183,
but it doesn't matter).
The issue occurs when SEMS unifies different To_tags from leg_B in an unique
To_tag in leg_A. This problem would dissapear if SEMS uses a different
To_tag in leg_A for each different To_tag received in leg_B.
For example, the To_tag in leg_A could be generated based on To_tag in leg_B:
leg_a_to_tag = create_tag(received_leg_b_to_tag)
SIP flow (I've deleted somw headers):
---------------------------------------------------
*** 180 from alice (leg_B):
# PROXY_IP -> SEMS_IP
SIP/2.0 180 Ringing
To: <sip:[EMAIL PROTECTED]>;tag=vgbom
From: "X-Lite" <sip:[EMAIL PROTECTED]>;tag=91aad98427871b752a72c9aa39824831
Call-ID: YWNhNzJkZWEwNzFmMjIxZjJlNmZjNjAxY2MxNTM3Y2U.-b2b_1
CSeq: 200 INVITE
Contact: <sip:[EMAIL PROTECTED];transport=tcp>
Server: Twinkle/1.3
----------------------------
*** 180 from bob (leg_B):
# PROXY_IP -> SEMS_IP
SIP/2.0 180 Ringing
To: <sip:[EMAIL PROTECTED]>;tag=kpsse
From: "X-Lite" <sip:[EMAIL PROTECTED]>;tag=91aad98427871b752a72c9aa39824831
Call-ID: YWNhNzJkZWEwNzFmMjIxZjJlNmZjNjAxY2MxNTM3Y2U.-b2b_1
CSeq: 200 INVITE
Contact: <sip:[EMAIL PROTECTED];transport=udp>
Server: Twinkle/1.3
----------------------------
*** 180 from SEMS (bob) to X-Lite (Leg_A):
# SEMS_IP -> X-Lite
SIP/2.0 180 Ringing
From: X-Lite <sip:[EMAIL PROTECTED]>;tag=34243d29
To: fork <sip:[EMAIL PROTECTED]>;tag=126d983702f40667910c0d06d9a0301c
Call-ID: YWNhNzJkZWEwNzFmMjIxZjJlNmZjNjAxY2MxNTM3Y2U.
CSeq: 1 INVITE
Server: SEMS
----------------------------
*** 180 from SEMS (alice) to X-Lite (Leg_A):
# SEMS_IP -> X-Lite
SIP/2.0 180 Ringing
From: X-Lite <sip:[EMAIL PROTECTED]>;tag=34243d29
To: fork <sip:[EMAIL PROTECTED]>;tag=126d983702f40667910c0d06d9a0301c
Call-ID: YWNhNzJkZWEwNzFmMjIxZjJlNmZjNjAxY2MxNTM3Y2U.
CSeq: 1 INVITE
Server: SEMS
Hope it's useful. Best regards.
--
Stefan Sayer
VoIP Services
[EMAIL PROTECTED]
www.iptego.com
IPTEGO GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Semsdev mailing list
Semsdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/semsdev
