I think we would have been well advised to put more rules on how this is used by those that understand it:
- if an offer contains a={sendonly,recvonly,sendrecv,inactive}, then the answer must also contain one of those, subject to the other rules for which ones are valid. In other words, can only use default in the answer if the offer used the default.
- offers should not use the default either, thus distinguishing them from offerers that don't support this.
If that were in place, or if you believe it is usually honored already, then I think you can try a=sendonly to initiate hold. A valid answerer will not reject this even if it isn't understood. If an answer is received, but doesn't contain a proper a-line response to this, then do another offer/answer cycle with c=0.0.0.0.
Starting out the first time with c=0.0.0.0 has a downside in that then the media stream is lost while on hold. This has nasty implications for firewalls, NATs, and QoS.
Paul
[EMAIL PROTECTED] wrote:
CS,
Thanks your response it makes great sense and I will look to implement support it in the way you describe. I guess it is really with the individual UA to use the 'a' line, 3264 says that the UA MAY omit this if the initial session is a normal bidirectional (a telephone call) as a=sendrecv is the default.
Thanks again, regards.
Wayne Davies email: [EMAIL PROTECTED]
*"Christian Stredicke" <[EMAIL PROTECTED]>*
07/04/2004 02:50 PM
To: <[EMAIL PROTECTED]>
cc: <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] Use of Supported header field to indicate support of the new Offer / Answer hold method.
We had the same problem with some user agents that dont support the new method. The only way that we got it working is:
- By default, use the old method with 0.0.0.0, but always include the a= sendrecv/recvonly/sendonly/inactive information in the SDP. Also for the initial INVITE!
- When receiving SDP, take a look at the a=sendrecv/recvonly/sendonly/inactive. If its there, the other side supports RFC3264.
- If the other side is recognized as RFC3264 UA, don't use 0.0.0.0 any more.
That seems to work in all cases. At least it fixed all the trouble tickets that we got after supporting RFC3264.
CS
-----Original Message-----*
From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED]
Sent:* Wednesday, April 07, 2004 11:48 AM*
To:* [EMAIL PROTECTED]
Subject:* [Sip-implementors] Use of Supported header field to indicate support of the new Offer / Answer hold method.
Query on preferring the Offer / Answer model of placing a user on hold.
The method for placing a user on hold with the media address of 0.0.0.0 is deprecated in favour of the method described in RFC3264 with a=sendonly.
Take two scenarios:
Scenario 1. UA X is being placed on hold by UA Y, knowing that all UA's are to support the older method Y could just use 0.0.0.0 - this would work but this assumption means that rather than be deprecated this method is actually preferred !. This seems to be common at the moment.
Scenario 2. UA X is being placed on hold by UA Y, Y takes a guess and uses a=sendonly to place X on hold - this is hit and miss, if X does not support this it will return a 606 Not Acceptable (SDP mismatch) or similar and then I need to rely on logic in Y to formulate a new Re-Invite with the 0.0.0.0 method.
Can this be a candidate for the Supported header field ?, if a option tag could be defined for the 3264 method of hold then UA's can indicate their support for it, taking the guess work out it. I am unsure if this is the right candidate for the supported header and am wary of causing a trend to advertise suport for large amount of SIP extensions.
Example with a UA advertising it's support for the Offer / Answer model method of placing a call on hold, proposed option tag of "3264Hold" <-- feel free to call it something else !.
*************************************************************************************************************************
INVITE sip:[EMAIL PROTECTED]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 137.147.132.249:5060
From: <sip:[EMAIL PROTECTED]>;tag=1F7823B4-871
To: <sip:[EMAIL PROTECTED]>
Date: Thu, 12 Feb 2004 07:16:00 GMT
Call-ID: [EMAIL PROTECTED] *
Supported: timer,100rel, 3264Hold*
Min-SE: 1800
Cisco-Guid: 621192735-1549930968-2254358604-370246430
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO
CSeq: 102 INVITE
Max-Forwards: 6
Remote-Party-ID: <sip:[EMAIL PROTECTED]>;party=calling;screen=yes;privacy=off
Timestamp: 1076570160
Contact: <sip:[EMAIL PROTECTED]:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 279
*******************************************************************************************************************************
Thanks and regards,
Wayne Davies email: [EMAIL PROTECTED]
------------------------------------------------------------------------
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
