Subject: [Sipping] Re: [Sip] Music On Hold

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Feb 2004 00:36:09 -0500

inline, and moving to sipping.

Suha Cubukcuoglu wrote:

> Hi,
> 
> During an attended call transfer attempt, the transferred party
> (A-Party) is put on 'hold' by the transferor (B-Party) - i.e. no media
> stream flows from B to A and vice versa. While the A-Party is on hold,
> the B-Party can INVITE a third party to play 'Music on Hold' tune to the
> A-Party until the transfer attempt succeeds. We think that there are
> complications in this approach. Firstly, the SIP Proxy must now where to
> route the new INVITE generated by the B-Party. If the destination URI is
> [email-masked]', the SIP Proxy must either do a DNS query or use
> its IP dial-plans to know where to route the call.

Sure. The URI needs to exist and be routable in the domain. Why is this 
a problem?

> Secondly, the B-Party
> might eventually end-up receiving the music tune whereas it was
> initially intended for the A-Party - we've had problems in the past
> because of this. 

If the INVITE contains sdp pointing the media to the a-party (which it 
should), this shouldnt happen. Is your on-hold server ignoring the 
address in the SDP?

> We think that third party invitation is a bad idea, and it would rather
> be more suitable to have a dedicated server (IVR unit perhaps) which the
> SIP Proxy Server can transfer calls to/from upon request for a MOH
> service. Could you tell us your opinions about this please?

Proxies dont transfer calls, as they dont maintain call state.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christian Stredicke" <[email-masked]>
Date: Wed, 4 Feb 2004 08:06:33 +0100

I am still convinced we need a more lightweight model that puts less burden
on the user agent which puts someone on hold. I mean, which user agent does
implement the model with a media server?

Why don't we just provide a music-URL like in Alert-Info? The other user
agent then can pick whatever it likes (http/WAV, sip, MIDI or whatever). I
think that's ten times easier.

BTW this information could also be inserted by the proxy (without
maintaining call state). This avoids the problem of setting the user agents
up for this.

Christian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Rosenberg
> Sent: Wednesday, February 04, 2004 6:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] Re: [Sip] Music On Hold
>

---

From: "F.S.Salloum" <[email-masked]>
Date: Wed, 4 Feb 2004 09:24:57 +0200

Hi, please find my opinions inline

>>Christian Stredicke
>>Sent: Wednesday, February 04, 2004 9:07 AM
>>To: 'Jonathan Rosenberg'; [email-masked]
>>Cc: [email-masked]
>>Subject: RE: [Sipping] Re: [Sip] Music On Hold

>>implement the model with a media server?

A lot of commercial product also our HW phones(http://netphone.intracom.gr/)
support this approach with no problem

>>think that's ten times easier.

I think we should consider security issues check this link with a
discussions with alert info stuff
(http://www.atm.tut.fi/list-archive/sip/msg01278.html) 

>>Christian

Enjoy
Sotiris

---

From: "Christian Stredicke" <[email-masked]>
Date: Wed, 4 Feb 2004 09:37:31 +0100

Comments inline!

> F.S.Salloum
> Sent: Wednesday, February 04, 2004 8:25 AM
> To: 'Christian Stredicke'; 'Jonathan Rosenberg'; [email-masked]
> Cc: [email-masked]
[Christian Stredicke] We also support this, but I can't say "no problem".
It's easy to get it working in the lab, but the real world shows us a
different picture. Calls get lost (people just plug the cable), transfer
fails, people are sitting behind NAT, media server running out of resources,
media server and negotiated codec don't find a common codec (cause only the
answer is available). Maybe is a question of the pain level, but for us it's
a "problem".

Of course, anything can be solved, but what I am trying to say is the
Alert-Info model would be much simpler. We could have the same discussion in
ring tones!!!

> (http://www.atm.tut.fi/list-archive/sip/msg01278.html)
[Christian Stredicke] There are also (bigger?) security problems with the
3PCC model. And the Alert-Info security problem has to be solved anyway (or
has been solved already).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Feb 2004 02:36:27 -0500

inline.

> Alert-Info model would be much simpler. We could have the same discussion in

Its not clear to me that many of the problems you list above would go 
away with an Alert-Info style approach. Certainly, those calls can get 
lost, there can be nat problems, the server can still run out of 
resources, etc.

You also indicate that there is a problem finding a common codec. Of 
course, if there are simply no codecs in common no signaling in the 
world will help. However, I don't think thats what you mean. In the flow 
in the service examples draft, the user placing the call on hold 
(b-party) issues an invite to the music on hold server with no sdp. That 
triggers the music on hold server to issue an offer with a full codec 
list. That is passed to the A-party, which picks the one(s) it wants. 
Thus, the music on hold can use different codecs than what is negotiated 
in the call between A and B. So, I dont see a specific problem. Can you 
elaborate on the difficulty you see?

> has been solved already).

3pcc in this specific case is not so hard, since (presumably) there is a 
relationship between the b-party and the music on hold server. If the 
B-party rather tells the A-party to contact the music on hold server 
directly (using an alert-info kind of approach), now there needs to be a 
security relationship between the A-party on the music on hold server, 
which doesnt exist. Relaying signaling through the B-party makes the 
security more tenable, I think.

-Jonathan R.

---

From: "Christian Stredicke" <[email-masked]>
Date: Tue, 10 Feb 2004 17:10:31 +0100

Hi Jonathan,

I wrote something about this topic on

http://softarmor.com/wgdb/docs/draft-stredicke-sipping-late-media-01.txt

Of course, technically it would be possible to initiate a conference with
3PCC that mixes billing beeps into the audio stream. Maybe someone can prove
that 3PCC is a Turing-machine; then we can stop the discussion if something
is possible with this model. But I doubt that this will be a big success.

Today I had another discussion with a customer that wanted to know why music
on hold is NOT working with a phone (from a very popular vendor, not us)
which is (big surprise) NOT initiating 3PCC MOH. Maybe, again, I am too
stupid to see the configuration option in the product of another vendor.

Or just use a B2BUA...

CS

> Sent: Thursday, February 05, 2004 8:36 AM
> To: Christian Stredicke
> Cc: 'F.S.Salloum'; [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: [Sip] Music On Hold
> 
> inline.
>