From what I can see of the example below there is only one problem -
the version number in the 2nd answer should have been incremented.
As written, the offerer could proceed on the assumption that the answer
has not changed. In this case that would do no harm. In some other cases
it might.
Paul
Stefan Sayer wrote:
> [EMAIL PROTECTED] wrote:
>> In regard to how the answer may be different from the offer, the rules
>> are in section 6.1 of RFC 3264. In many cases, the answerer may add
>> media formats. E.g.,
>>
>> For streams marked as sendrecv in the answer, the "m=" line MUST
>> contain at least one codec the answerer is willing to both send and
>> receive, from amongst those listed in the offer. The stream MAY
>> indicate additional media formats, not listed in the corresponding
>> stream in the offer, that the answerer is willing to send or
>> receive (of course, it will not be able to send them at this time,
>> since it was not listed in the offer).
> the payloads from the second answer are the same as the ones from the
> second offer (just in different order):
>
> 1st offer:
> Session ID: 251733463
> Session Version: 1181517354
> payloads: 3 98 97 8 0 101
> 1st answer:
> Session ID: 162119823
> Session Version: 1294106766
> payloads: 3 101
>
> ...
>
> 2nd offer:
> Session ID: 251733463
> Session Version: 1181517354
> payloads: 3 98 97 8 0 101
> 2nd answer:
> Session ID: 162119823
> Session Version: 1294106766
> payloads: 98 97 8 0 3 101
>
>> In any case, if one is trying to debug SDP, one should have read RFC
>> 3264 carefully.
> how true.
>
> Regards
> Stefan Sayer
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
