[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Query of receiving re-INVITE without offer
From:       Paul Kyzivat <pkyzivat () cisco ! com>
Date:       2011-01-19 15:45:50
Message-ID: 4D37072E.2010303 () cisco ! com
[Download RAW message or body]



On 1/19/2011 4:13 AM, Sunil wrote:
> Hi All,
>
> Please clarify how to handle the below requirement of rfc 3261in case of
> 3 scenarios: The UAS MUST ensure that the session description overlaps
> with its previous session description in media formats, transports, or
> other parameters that require support from the peer.
>
> 1. User A and User B are in connected state and user A receives a
> re-INVITE without offer. in this case the OFFER sent in 2xx (which is
> expected to be like an initial offer) may vary with the existing ongoing
> session's negotiated parameters. is it ok if user A sends offer with all
> capabilities even if it knows that user B des not support all the
> capabilities.Can user A receive re-INVITE without offer from a proxy??

Not only is it *ok*, it is the optimal thing to do.
It cannot *know* what B supports now. It only knows something of what B 
supported at the last o/a exchange, and even then its knowledge is 
likely incomplete. And there is no harm in offering all capabilities, 
since B can still reject those it currently doesn't support.

This becomes critical in a 3pcc transfer scenario. In that case A is 
really a B2BUA, and is intended to transfer the call to another UA that 
may have entirely different capabilities than those currently in use.

Of course A may choose not to offer all of its capabilities, for its own 
reasons. For instance it may have video capability but choose not to 
offer it because it is operating in no-video mode.

> 2. User A and User B are on HOLD and user A receives a re-INVITE without
> offer. then what should be the direction mode in offer??

Depends on A's local state. If A had previously initiated HOLD, and 
still wants the call on hold, then it should send offer with sendonly 
(or inactive if it doesn't want to send MoH). If A had preferred to be 
sendrecv but is currently in recvonly or inactive due to prior action by 
B, then it should offer sendrecv and let B decide what to respond with. 
(Doing otherwise can result in a "stuck on hold" situation if both ends 
put the call on hold.)

> 3. User A and User B are in a FAX session (which was negotiated through
> re-INVITE after audio session) and user A receives a re-INVITE without
> offer, what shoud the offer contain audio media stream details or fax
> media stream details.

Whatever it prefers. There is no perfect solution here. For dedicated 
fax machines it may make sense to offer fax again.

One solution would be to offer both, as separate m-lines and let the 
other end decide. Or it could use the new SDP capability negotiation 
framework (RFC 5939) to offer one but indicate support for the other as 
well.

> Also if a SIP Stack supports RFC 3407(Session Description Protocol (SDP)
> Simple Capability Declaration) can it override the above requirement
> ie., the offer in 2xx will contain the negotiated media stream and
> include the capability specific attributes which includes all the media
> formats, all parameters etc.

I don't know about 3407 except that it has been superseded by 5939.

	Thanks,
	Paul

> Many thanks in advance for your precious time..
>
> Regards,
>
> Sunil
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

[prev in list] [next in list] [prev in thread] [next in thread]