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

[Iñaki Baz Castillo <[e-mail]>]

2012/6/29 Anne Raby <[e-mail]>:
> 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
<[e-mail]>