Subject: Re: [Sip] INFO

From: "Eric Burger" <[email-masked]>
Date: Fri, 12 Oct 2007 02:44:35 -0700

Routing of the message once it gets to the device (application), not route to the device (transport).

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

----- Original Message -----
From: Christer Holmberg <[email-masked]>
To: Eric Burger; Hadriel Kaplan <[email-masked]>
Cc: sip <[email-masked]>
Sent: Thu Oct 11 19:38:06 2007
Subject: RE: [Sip] INFO

Hi Eric,

I am not sure I understand what you mean, but INFOs are routed according
to the route set of the invite dialog they are sent within.

If you want to transport information using some other path you can of
course not send the information within the invite dialog.

Regards,

Christer

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: 12. lokakuuta 2007 0:35
> To: Christer Holmberg; Hadriel Kaplan
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> Right: "DTMF may not be the only information users want to 
> send to each other during a session."  This is why one MUST 
> establish multiple subscription dialogs.  How else would one 
> keep track of the different elements / local routing 
> decisions?  If you are proposing application routing a'la 
> P-Asserted-Service...
> 
> 
> On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)"
> <[email-masked]> wrote:
> 
> > 
> > 
> > Hi,
> > 
> > Let's also keep in mind that DTMF may not be the only information 
> > users want to send to each other during a session. So, you 
> will need 
> > to establish subscription dialogs for every type of event that the 
> > users may want to send during the session...
> > 
> > Regards,
> > 
> > Christer
> > 
> >> -----Original Message-----
> >> From: Christer Holmberg (JO/LMF)
> >> [mailto:[email-masked]]
> >> Sent: 11. syyskuuta 2007 12:27
> >> To: Hadriel Kaplan; Eric Burger
> >> Cc: sip
> >> Subject: RE: [Sip] INFO
> >> 
> >> 
> >> Hi,
> >> 
> >>>> Consider a PSTN call.  The call goes from the gateway to
> >> softswitch /
> >>>> Proxy.  Proxy routes to VM App Server.  INFO has to pass through 
> >>>> softswitch / Proxy.
> >>>> In KPML-land, VM App Server *directly* subscribes to UAC 
> key press
> >> state, bypassing the softswitch.
> >> 
> >> [Christer] As I've said before, there are environments where some 
> >> proxies must (for whatever reason) be passed through. I guess an 
> >> outbound proxy is a good example.
> >> 
> >>>> KPML and INFO have the same number of messages for a 
> SINGLE digit;
> >> KPML wins
> >>>> hands-down for multiple digits or reports.
> >>> 
> >>> Not exactly - for a single digit, KPML would generate a 
> >>> Subscribe/200/Notify/200 before the single DTMF was even 
> pressed - 
> >>> before the actual Notify with the digits in it.
> >>> And of course there is now also a subscribe dialog involved.
> >>> Assuming a one-shot single digit type, then, we're talking 6 SIP 
> >>> messages for KPML vs. 2 for Info.
> >> 
> >> [Christer] And, in cases where you need to send DTMFs (or whatever
> >> information) in both directions you actually need 2 subscription 
> >> dialogs
> >> - one in each direction, and maintaining dialog state also 
> consumes 
> >> resources. And, in some cases you may not even know 
> whether you will 
> >> ever have to use the dialog.
> >> 
> >> 
> >>>> More importantly, let's take a Call Management (CM)
> >> application that
> >>>> calls a VM application when they cannot find the
> >> subscriber.  INFO has
> >> 
> >>>> to pass through the softswitch / Proxy to the CM
> >> application.  Cool -
> >>>> it is a proxy, so it knows to relay.  But OOPS!  The CM 
> application 
> >>>> has to proxy the INFOs to the VM application.  Yes - you 
> could be a 
> >>>> good programmer and remember to do that EVERYWHERE you place an 
> >>>> outbound call, but it is really easy to get wrong.
> >>> 
> >>> I'm not sure I understand the scenario.  The VM learned 
> about this 
> >>> call how?
> >>> By being in the signaling path, no?  So why wouldn't the 
> CM forward 
> >>> INFO along the path? (I mean it is in the same dialog, 
> after all)  
> >>> Now I don't doubt it could screw that up, and eat the 
> info thinking 
> >>> it was for itself, but lots of things can get screwed up 
> - my guess 
> >>> is KPML will not be impervious to screw ups.
> >> 
> >> [Christer] I also have problems understanding the 
> scenario. INFO is 
> >> routed to wherever the INVITE that initiated the dialog 
> was routed...
> >> 
> >> Regards,
> >> 
> >> Christer
> >> 
> >> 
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >> 
> > 
> 
> 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 14 Oct 2007 17:01:30 +0200

Hi,

As I have said before: you have similar problems with other mechanisms.

Regards,

Christer

> Sent: 12. lokakuuta 2007 12:45
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> Routing of the message once it gets to the device 
> (application), not route to the device (transport).
> 
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all 
> need lemonade: see 
> <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
> 
> I am not sure I understand what you mean, but INFOs are 
> routed according to the route set of the invite dialog they 
> are sent within.
> 
> If you want to transport information using some other path 
> you can of course not send the information within the invite dialog.
> 
> Regards,
> 
> Christer
> 
> 
> > Right: "DTMF may not be the only information users want to send to 
> > each other during a session."  This is why one MUST 
> establish multiple 
> > subscription dialogs.  How else would one keep track of the 
> different 
> > elements / local routing decisions?  If you are proposing 
> application 
> > routing a'la P-Asserted-Service...
> > 
> > 
> > >> Sent: 11. syyskugw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST)
Content-class: urn:content-classes:message
Subject: RE: [Sip] INFO
Date: Sun, 14 Oct 2007 17:01:30 +0200
From: "Christer Holmberg" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: [email-masked]

Hi,

As I have said before: you have similar problems with other mechanisms.

Regards,

Christer

> Sent: 12. lokakuuta 2007 12:45
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> Routing of the message once it gets to the device 
> (application), not route to the device (transport).
> 
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all 
> need lemonade: see 
> <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
> 
> I am not sure I understand what you mean, but INFOs are 
> routed according to the route set of the invite dialog they 
> are sent within.
> 
> If you want to transport information using some other path 
> you can of course not send the information within the invite dialog.
> 
> Regards,
> 
> Christer
> 
> 
> > Right: "DTMF may not be the only information users want to send to 
> > each other during a session."  This is why one MUST 
> establish multiple 
> > subscription dialogs.  How else would one keep track of the 
> different 
> > elements / local routing decisions?  If you are proposing 
> application 
> > routing a'la P-Asserted-Service...
> > 
> > 
> > >> Sent: 11. syyskugw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST)
Content-class: urn:content-classes:message
Subject: RE: [Sip] INFO
Date: Sun, 14 Oct 2007 17:01:30 +0200
From: "Christer Holmberg" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: [email-masked]

Hi,

As I have said before: you have similar problems with other mechanisms.

Regards,

Christer

> Sent: 12. lokakuuta 2007 12:45
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> Routing of the message once it gets to the device 
> (application), not route to the device (transport).
> 
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all 
> need lemonade: see 
> <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
> 
> I am not sure I understand what you mean, but INFOs are 
> routed according to the route set of the invite dialog they 
> are sent within.
> 
> If you want to transport information using some other path 
> you can of course not send the information within the invite dialog.
> 
> Regards,
> 
> Christer
> 
> 
> > Right: "DTMF may not be the only information users want to send to 
> > each other during a session."  This is why one MUST 
> establish multiple 
> > subscription dialogs.  How else would one keep track of the 
> different 
> > elements / local routing decisions?  If you are proposing 
> application 
> > routing a'la P-Asserted-Service...
> > 
> > 
> > >> Sent: 11. syyskugw4.ericsson.se (Symantec Mail Security) with ESMTP id
	D6D2A20101; Sun, 14 Oct 2007 17:01:31 +0200 (CEST)
Content-class: urn:content-classes:message
Subject: RE: [Sip] INFO
Date: Sun, 14 Oct 2007 17:01:30 +0200
From: "Christer Holmberg" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: [email-masked]

Hi,

As I have said before: you have similar problems with other mechanisms.

Regards,

Christer

> Sent: 12. lokakuuta 2007 12:45
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> Routing of the message once it gets to the device 
> (application), not route to the device (transport).
> 
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all 
> need lemonade: see 
> <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
> 
> I am not sure I understand what you mean, but INFOs are 
> routed according to the route set of the invite dialog they 
> are sent within.
> 
> If you want to transport information using some other path 
> you can of course not send the information within the invite dialog.
> 
> Regards,
> 
> Christer
> 
> 
> > Right: "DTMF may not be the only information users want to send to 
> > each other during a session."  This is why one MUST 
> establish multiple 
> > subscription dialogs.  How else would one keep track of the 
> different 
> > elements / local routing decisions?  If you are proposing 
> application 
> > routing a'la P-Asserted-Service...
> > 
> > 
> confideuta 2007 12:27
> confideuta 2007 12:27
> confideuta 2007 12:27

---

From: Eric Burger <[email-masked]>
Date: Sun, 14 Oct 2007 19:52:53 -0400

No.   For subscribe/notify interaction, it is trivial: whomever issues the
subscribe gets the notify. Easy for the stack to figure out.  For INFO
interaction, everything goes to call control. That works if your model is
pure softswitch/feature server, but not many folks are doing that anymore.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Oct 2007 11:03:48 +0200

Hi, 
	
>No. For subscribe/notify interaction, it is trivial: whomever issues
the subscribe gets the notify. Easy for the stack to figure out.  For
INFO 
>interaction, everything goes to call control. That works if your model
is pure softswitch/feature server, but not many folks are doing that
anymore.

Assume two applications are interested of the same event, so they both
subscribe to it. Now, how does the SENDER know to which subscription to
use for a specific application?

Regards,

Christer

		
		Hi,
		
		As I have said before: you have similar problems with
other mechanisms.
		
		Regards,
		
		Christer
		
		> <http://www.standardstrack.com/ietf/lemonade>
		> > > to establish subscription dialogs for every type
of event
		> that the
		> > >>>> Proxy.  Proxy routes to VM App Server.  INFO
has to
		> pass through
		> > >> [Christer] As I've said before, there are
environments
		> where some
		> > >>> Assuming a one-shot single digit type, then,
we're
		> talking 6 SIP
		> > >> [Christer] And, in cases where you need to send
DTMFs
		> (or whatever
		> > >>>> good programmer and remember to do that
EVERYWHERE you
		> place an
		> > >> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
		> error, please immediately return this by email and
then delete it.

	
	Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary, copyrighted
and/or legally privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not the intended
recipient, and have received this message in error, please immediately
return this by email and then delete it.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2007 08:23:32 -0400

> use for a specific application?

Is this a trick question? Or don't I understand you?

If two applications have concurrent and identical subscriptions for the 
same event then they should both receive equivalent notifications.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Oct 2007 19:54:20 +0200

Hi, 

>>>No. For subscribe/notify interaction, it is trivial: 
>>>whomever issues the subscribe gets the notify. Easy for the stack to
figure 
>>>out.  For INFO
>>>interaction, everything goes to call control. That works if your 
>>>model is pure softswitch/feature server, but not many folks are 
>>>doing that anymore.
>> 

>>subscribe to it. Now, how does the SENDER know to which subscription 
>>to use for a specific application?
> 
>If two applications have concurrent and identical 
>subscriptions for the same event then they should both 
>receive equivalent notifications.

Yes, and that means that both applications will receive the event, even
if the sender only intended to send the event to one of the
applications.

So, in that case: if the same information is sent in an INFO, the
receiver will provide it to both application that has indicated to the
stack that they want that type of information to be dispatched to them.

Regards,

Christer

> > 
> > 	
> > 	
> > 
> > 		
> > 		
> > 		Hi,
> > 		
> > 		As I have said before: you have similar 
> problems with other 
> > mechanisms.
> > 		
> > 		Regards,
> > 		
> > 		Christer
> > 		
> > 		> you can of course not send the information 
> within the invite 
> > dialog.
> > 		>
> > 		> Regards,
> > 		>
> > 		> Christer
> > 		>
> > 		>
> > 		> > Right: "DTMF may not be the only 
> information users want to send 
> > to
> > 		> > > Let's also keep in mind that DTMF may not 
> be the only 
> > information
> > 		> > > to establish subscription dialogs for 
> every type of event
> > 		> that the
> > 		> > >>>> Proxy.  Proxy routes to VM App Server. 
>  INFO has to
> > 		> pass through
> > 		> > >>>> softswitch / Proxy.
> > 		> > >> [Christer] As I've said before, there 
> are environments
> > 		> where some
> > 		> > >> proxies must (for whatever reason) be 
> passed through. I guess 
> > an
> > 		> > >>> Assuming a one-shot single digit type, 
> then, we're
> > 		> talking 6 SIP
> > 		> > >> [Christer] And, in cases where you need 
> to send DTMFs
> > 		> (or whatever
> > 		> > >>>> good programmer and remember to do 
> that EVERYWHERE you
> > 		> place an
> > 		> > >> [email-masked] for new developments on 
> the application of 
> > sip
> > 		> > >>
> > 		> > >
> > 		> >
> > 		> >
> > 		> >
> > 		> > error, please immediately return this by 
> email and then delete 
> > it.
> > 		> >
> > 		>
> > affiliated entities, that may be confidential, proprietary, 
> > copyrighted and/or legally privileged, and is intended 
> solely for the 
> > use of the individual or entity named in this message. If 
> you are not 
> > the intended recipient, and have received this message in error, 
> > please immediately return this by email and then delete it.
> > 
> > 
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2007 15:08:46 -0400

> stack that they want that type of information to be dispatched to them.

I have lost my way in this conversation.

In the context of sub/not when we talk about multiple applications being 
interested in the same event, they are typically not resident in the 
same UA. For instance for DTMF we may have a pre-paid application acting 
as a B2BUA and an IVR at the far end that also wants to interact with 
the caller.

You are talking about two applications resident in the same UA. That is 
usually outside the scope of our discussions.

In general the source if the info (the notifier or sender of INFO) won't 
know where it wants to send the info, or that there might be multiple 
consumers of it. In the case of sub/not it is told this by SUBSCRIBEs. 
In the case of INFO there really isn't any point in it knowing if there 
are multiple consumers, since that won't alter its behavior.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Oct 2007 23:10:15 +0200

Hi, 
 
>>>>>whomever issues the subscribe gets the notify. Easy for 
>>>>>the stack to figure out.  For INFO
>>>>Assume two applications are interested of the same event, so they 
>>>>both subscribe to it. Now, how does the SENDER know to which 
>>>>subscription to use for a specific application?
>>>If two applications have concurrent and identical subscriptions for 
>>>the same event then they should both receive equivalent 
>>>notifications.
>> 
>>Yes, and that means that both applications will receive the event, 
>>even if the sender only intended to send the event to one of the 
>>applications.
>> 

>In the context of sub/not when we talk about multiple 
>applications being interested in the same event, they are 
>typically not resident in the same UA. 
>
>For instance for DTMF we may have a pre-paid application acting as a
B2BUA and an 
>IVR at the far end that also wants to interact with the caller.

Then the B2BUA has to be designed in a way so things works. It can
choose to collect the pre-paid DTMFs before contacting the IVR, or
something else. It's not up to us to design those B2BUAs.  
 
>You are talking about two applications resident in the same 
>UA. That is usually outside the scope of our discussions.

I would hope so, but I think Eric brought this case up at one point.

>In general the source if the info (the notifier or sender of 
>INFO) won't know where it wants to send the info, or that 
>there might be multiple consumers of it. In the case of 
>sub/not it is told this by SUBSCRIBEs. 
>In the case of INFO there really isn't any point in it 
>knowing if there are multiple consumers, since that won't 
>alter its behavior.

Fine, so it's not a problem then.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 16:21:57 -0500

On Oct 16, 2007, at 4:03 AM, Christer Holmberg wrote:

>> model

In 3265, by which application is holding the dialog.

With events in an INVITE bounded dialog, we don't have that extra bit  
of demux, and everything goes through the application holding the  
INVITE dialog, which then gets to figure out what's going on.

--
Dean