I gather that UAS is actually a B2BUA.
Does it also terminate and relay media?
Or does it simply forward media descriptions from one leg to the other?
(I suspect from your description that it terminates and relays media.)
As long as it is functioning as a B2BUA, there is nothing obviously
wrong *technically* with what it has done. Its free to manage the two
dialogs independently as it wishes.
As long as it terminates the video stream from UAS1, and doesn't forward
the video while UAS2 has video set to inactive, it is also working in a
defensible way, though perhaps not the most obvious way.
This is probably an area where the application is just not working the
way you would wish, but the issues are not related to standards.
Thanks,
Paul
On 12/6/2010 7:08 AM, [email protected] wrote:
> Hi All!
>
> My question about a=inactive attribute of SDP and re-INVITE.
> We have implemented re-INVITE for our UAC. Our re-INVITE changes media
> session and add video
> codecs to SDP and it works and tested with some sip proxies.
>
> But with Asterisk and Bria, we have strange behavior:
> Assume, that Asterisk is UAS and Bria is UAC1, UAC2
>
> 1. UAC1 INVITE to UAS with audio codecs only in SDP, audio a=sendrecv
>
> 2. UAS INVITE to UAC2 with audio and video codecs in SDP, audio
> a=sendrecv, video a=sendrecv
>
> 3. UAC2 200 OK to UAS with audio and video codecs in SDP, audio
> a=sendrecv, video a=inactive
>
> 4. UAC1 re-INVITE to UAS with audio codecs and video codecs,
> a=sendrecv, video a=sendrecv
>
> 5. UAS 200 OK to UAC1 with audio codecs and video codecs,
> a=sendrecv, video a=sendrecv
>
> 6. ACKs...
>
> Then RTP audio+video conversation has been established.
>
> But in this scenario, UAS does not transmit re-INVITE to UAC2 at all.
> Is it rfc3261 violation?
>
> UAC2 starts send RTP video packets after packets received
> from UAS.
>
> Is it correct implementation or workaround? - to start sending RTP
> packets after receiving packets from the far end? If it is not workaround.
> What specification describes it?
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
