On 1/10/14 3:40 AM, Praveena Ss wrote:
> Hi Isshed,
>
> in your example, second offer from A is correct as long as session version
> id is changed in same session.
I disagree. The operable issue is in section 8 of 3264:
If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in
the previous SDP. In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines. The i-th media
stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top. This matching is
necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP. Because of
these requirements, the number of "m=" lines in a stream never
decreases, but either stays the same or increases. Deleted media
streams from a previous SDP MUST NOT be removed in a new SDP;
however, attributes for these streams need not be present.
I think the confusion here may be around the word "session", which has
two possible meanings in this context:
- an SDP session
- a signaling (e.g., SIP) session
This isn't entirely clear in the text, but it is widely understood that
for SIP this is to be a SIP session. (Specifically, an INVITE dialog usage.)
> w.r.t m= line, the second answer sent from B
> is wrong because it does not contain the same number of m= lines as in
> second offer from A.
This is probably true. But since the 2nd offer was in error there is no
good way to define what the proper behavior should be.
Thanks,
Paul
> Hope this helps to you.
>
> snippet from RFC 3264,
>
> 6 Generating the Answer
>
> .
> .
> For each "m=" line in the offer, there MUST be a corresponding "m="
> line in the answer. The answer MUST contain exactly the same number
> of "m=" lines as the offer. This allows for streams to be matched up
> based on their order. This implies that if the offer contained zero
> "m=" lines, the answer MUST contain zero "m=" lines.
>
> .
> .
> .
>
> Thanks and regards,
> -Praveen
>
>
>
> On Fri, Jan 10, 2014 at 12:11 PM, isshed <isshed....@gmail.com> wrote:
>
>> Hi All,
>>
>> Below is offer answer model between UA A and B.
>>
>>
>> [Offer From A]
>>
>> v=0
>> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
>> s=
>> c=IN IP4 host.atlanta.example.com
>> t=0 0
>> m=audio 49170 RTP/AVP 0 8 97
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:97 iLBC/8000
>> m=video 51372 RTP/AVP 31 32
>> a=rtpmap:31 H261/90000
>> a=rtpmap:32 MPV/90000
>>
>>
>> [Answer From B]
>>
>> v=0
>> o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
>> s=
>> c=IN IP4 host.biloxi.example.com
>> t=0 0
>> m=audio 49172 RTP/AVP 0 8
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> m=video 0 RTP/AVP 31
>> a=rtpmap:31 H261/90000
>>
>> [Second-Offer From B]
>>
>> v=0
>> o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
>> s=
>> c=IN IP4 host.atlanta.example.com
>> t=0 0
>> m=audio 51372 RTP/AVP 0
>> a=rtpmap:0 PCMU/8000
>>
>> [Second-Answer From A]
>>
>> v=0
>> o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
>> s=
>> c=IN IP4 host.biloxi.example.com
>> t=0 0
>> m=audio 49172 RTP/AVP 0
>> a=rtpmap:0 PCMU/8000
>> m=video 0 RTP/AVP 31
>> a=rtpmap:31 H261/90000
>>
>>
>> Is it a valid offer answer model, as [Second-Offer From B] removes
>> one of the m line?
>>
>> Thanks.
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
