Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 4 Jul 2012 00:13:23 +0200

2012/6/29 Anne Raby <[email-masked]>:
> I am trying to reconcile this example with RFC3261, RFC3262 and RFC3264. With the help of RFC 6337, I understand that if a UAC receives a SDP answer in a reliable response, it should ignore any SDP ANSWER in a subsequent response in the same INVITE transaction. If the 2nd SDP is different then the UAC should only consider the 1st SDP answer.

Hi, that's not correct. Let me improve it:

If a UAC receives a SDP answer in a reliable response (with To-tag =
AAAA), then any subsequent provisional or final response (with SDP)
within the same transaction and *same* To-tag MUST contain the same
SDP. Otherwise it would be a violation of RFC 3261.

But within the same INVITE transaction, the UAC could receive
different provisional (and also final 2XX) responses with *different*
To-tag and, therefore, with different SDP. And yes, the UAC could
choose which media stream(s) to render (or render all of them in some
exotic way).

> If this is the case, then the SDP answer from the 200 OK should be the same as in the 180. What is then the advantage of using the "pranswer" state? I am trying to figure out in which case the "pranswer" could be used?

Imagine you call a mobile number, the mobile rings for a while and you
get a 183 with To-tag = AAAA and SDP 1. After 30 seconds the operator
decides to route your call to a voicemail server which automatically
answers your call and replies a 200 OK with a different To-tag = BBBB
(since it's a different UAS) and SDP 2 (of course not the same as SDP
1).  That's a simple example of SIP serial forking, but the same is
tru for parallel forking (in which you could get different 18X
responses at the same time, with different To-tag and SDP).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 4 Jul 2012 09:30:41 +0200

> choose which media stream(s) to render (or render all of them in some
The documentation for early media doesn't really cover this case. We have set up tests for this
during many SIPit Interoperability events and devices have done different things with multiple
early media streams and answer from a separate device. Some latched on to early media and
ignored the final answer (200 OK), some mixed (awful experience) and some just ignored the
whole issue by staying with the first answer. 

> responses at the same time, with different To-tag and SDP).

Do we really need to map the PSTN call states into webrtc? Media is either active or onhold(inactive). Early media is just a billing issue and a state that could be managed by the app that controls the webrtc media.

In the case of the SIP stack, the SIP stack could be aware that media is early or complete from a SIP to PSTN call point of view - but what's the point of this complexity in Webrtc?

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 4 Jul 2012 13:22:25 +0200

2012/7/4 Olle E. Johansson <[email-masked]>:
> Do we really need to map the PSTN call states into webrtc?

I don't suggest that. I was just explaining the SIP case in which
different SDP are received by the UAC within the same INVITE
transaction :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 4 Jul 2012 14:27:41 +0200

> different SDP are received by the UAC within the same INVITE

And you where perfectly right. An OFFER can only have one ANSWER - but per early dialog in SIP. And one INVITE with an SDP offer can generate multiple early dialogs with multiple SDP answers, in PRACK or in 200 OK or somewhere else. The OFFER/ANSWER process is decoupled from the INVITE transaction, really.

/O ;-)

---

From: Anne Raby <[email-masked]>
Date: Wed, 4 Jul 2012 10:13:43 -0400

Thank you both for the clarifications.

/Anne
-----Original Message-----
From: Olle E. Johansson [mailto:[email-masked]] 
Sent: July-04-12 8:28 AM
To: Iñaki Baz Castillo
Cc: Anne Raby; [email-masked]
Subject: Re: [rtcweb] JSEP-01 Handling Early Media, using SIP, clarifications

/O ;-)