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]s.columbia.edu]
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]
