Klaus Darilion wrote:
Hi Inaki!
Where is it defined that the SDP must not be changed during a
transaction (of course it may be changed during a dialog (reINVITE))?
MAyb the B2BUA has to change the session id in the SDP (o=)
This one possibility, but I'm not sure this is the path that we want to
follow...
-Raphael.
regards
klaus
Iñaki Baz Castillo schrieb:
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.
_______________________________________________
Semsdev mailing list
Semsdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/semsdev
_______________________________________________
Semsdev mailing list
Semsdev@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/semsdev
