On Fri, 2008-06-06 at 15:41 -0400, Jeremy Geras wrote:
> Yeah, we looked at draft-worley-service-example-01, but concluded that
> it won't work for us because it doesn't allow the endpoint that is
> being put on hold to reject the music. (For example, a softphone that
> acts as a local audio mixer for a 3 party conference call -- if one of
> the participants tries to put the conference mixing UA on hold, we
> want to respond with appropriate SDP such that they are *not* allowed
> to send hold music to the conference).
The critical question if you want to avoid mixing MOH into a conference
is being able to detect that someone is sending (or offering) MOH.
Whether the MOH is implemented by either technique, the problem
presented to the held party is the same. The particular signaling
details by which the two methods differ do not provide this information,
because those signaling patterns can be used for other purposes as well.
And since the problem is presented to the conference phone, not the
phone putting the call on hold, the conference phone must be able to
deal with *any* technique for putting the call on hold, as it has no
controller over the other party.
In the example call flow in draft-ietf-sipping-service-examples-14, the
message carrying the SDP to the held party is F12:
INVITE sips:[EMAIL PROTECTED];gr SIP/2.0
Via: SIP/2.0/TLS server.example.com:5061;branch=z9hG4bK74rf
Max-Forwards: 70
From: <sips:[EMAIL PROTECTED]>;tag=0111
To: <sips:[EMAIL PROTECTED];gr>
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE
Referred-By: <sips:[EMAIL PROTECTED]>
Contact: <sips:[EMAIL
PROTECTED]>;automaton;+sip.byeless;+sip.rendering="no"
Require: replaces
Replaces: [EMAIL PROTECTED];from-tag=23431;to-tag=1234567
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v=0
o=MusicServer 2890844576 2890844576 IN IP4 server.example.com
s=
c=IN IP4 server.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
In the example in draft-worley-service-example-01#section-2.3, the
message is F10:
ACK sips:[EMAIL PROTECTED];gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061;branch=z9hG4bKq874b
To: Alice <sips:[EMAIL PROTECTED]>;tag=1234567
From: Bob <sips:[EMAIL PROTECTED]>;tag=23431
Call-ID: [EMAIL PROTECTED]
CSeq: 712 ACK
Contact: <sips:[EMAIL PROTECTED]>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844528 IN IP4 biloxi.example.com
s=
c=IN IP4 server.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
In both examples, the message carries two insignia of being on-hold: (1)
"+sip.rendering="no"" in the Contact header, and (2) "a=sendonly" in the
SDP.
Dale
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
