[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
--
iptego - VoIP security
www.iptego.de
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
