On 4/28/2011 3:01 AM, Nauman Sulaiman wrote:
> Hi,
>
> Scenario is as follows UAC makes call to UAS over Broadworks B2BUA and then
> UAC goes on hold. Broadworks periodically issues Session Audit with SDP
> version number unchanged, this is for UAC and UAS which do not support
> session timers or UPDATE method.
>
> UAC -------> Broadworks ------------> UAS
> INVITE ver=1 INVITE ver=1
> sendrecv sendrecv
> UAC<------- Broadworks<---------- UAS
> 200OK ver=1 200OK ver=1
> sendrecv sendrecv
>
> UAC goes on hold
>
> UAC------------> Broadworks -----------> UAS
> INVITE ver=2 INVITE ver=2
> sendonly inactive
>
> UAC<--------- Broadworks<--------- UAS
> 200OK ver=2 200OK ver =2
> inactive inactive
>
>
> Broadworks session audit (UPDATE not supported by UAC or UAS)
>
>
> UAC<------------ Broadworks
> INVITE ver=2
> inactive
> UAC--------------> Broadworks
> INVITE ver=2
> ??
The UAC has no choice here - it MUST respond as inactive. (That is the
only valid answer for an offer of inactive.) And that makes the SDP
different from what was in the one with ver=2, so it will have to be ver=3.
I presume this is what Brett was saying.
Thanks,
Paul
> With session Audit shown at the end, Broadworks sends the UAC a REINVITE with
> the session version unchanged. However the last SDP that the UAC sent
> broadworks had a media attribute of sendonly.
>
> What should the UAC send back in the media attribute field here, should SDP
> be unchanged if the version no. is unchanged but in this case we would send
> back the original sdp with an attribute of sendonly.
>
> I have seen UAs put inactive in this field, what is correct?
>
>
> Many 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
