Re: [dispatch] New version for the Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt

[<[e-mail]>]

You are right that discrete items and multiple URNs are much more
complex than the original hierarchical URNs. Multiple URNs add a lot of
new problems.
But do you see other possibility to solve Adam's issue? In principle, we
do not have the problem with the URN which we want to define in the
current draft, if we drop chapter 4.2 and only define the ringback tones
as country-specific. As John pointed out we can not send Alert-Info in a
busy-response anyway. 
Maybe we can restrict the IANA registration to Alert URNs which we know
people intend to implement? This will probably reduce the number
considerably, but the theoretical problem remains. 
I will take this as an open issue for the dispatch meeting slides. I
hope Adam will be there because it was his proposal to use combinations
of discrete items rather than hierarchy. I am open for both and also for
a new proposal. 

Additional comments inline.

> 
> I have a sip pbx phone on my desk. I don't have any distinction for 
> internal vs. external, and have no clue how "normal" would be 
> different 
> from one or the other of those. I don't really desire any 
> distinction on 
> any of those terms.

The scenario  you describe is also valid for me. I think it depends on
the job they are doing if people using a PBX wants to know a call is
internal or external. Call centres, sales people have other needs than
we have and as far as I know customers often require these features from
PBX-systems. I think Alan added this stuff to the draft because it is
required by Avaya's customers. 

> 
> > I would keep the two worlds disjunct. E.g. , I have a sip 
> handy which is
> > attached sometimes to the pbx and sometimes to my public carrier at
> > home, I may want the pbx ringing tone to be different from 
> the ringing
> > tone at home. 
> 
> I don't really have any objection to a bunch of "names" for extra 
> arbitrary ring types. The real issue is deciding when to use one or 
> another. Is the assumption here that these will typically be 
> inserted by 
> some agent acting on behalf of the phone acting on them, rather than 
> being inserted by "the other" party? IOW, *my* pbx decides that an 
> incoming call from you is "internal" or "external" and inserts a 
> suitable value by its policy, rather than *your* phone 
> deciding the call 
> is internal or external and inserting the value that I then render. 
> 
> It seems like you might have both models in mind. On one hand 
> *my* pbx 
> is deciding if the call to me is internal or external, but 
> the other end 
> is indicating it is a French phone rather than a US phone and so at 
> least ringback should be french.

I don't see the contradiction here:  external is inserted by the
PBX-system in the INVITE to my phone if the caller is external. How
could  my phone decide if the caller is external or internal?
If I call someone in France the French phone (or ist proxy) may insert
the Alert-Info URN for france into the 180 ringing response. 
These are for me two different scenarions. Or maybe I did not understand
you correctly?

I should probably change wording in the draft and use ringback instead
of ringing in connection with country tones. The current text is often
quite confusing.   

> 
> > 	> A nit: in 4.3.2 I would expext the forward to be indicated, 
> > 	> if at all, 
> > 	> with a 181 rather than a 180.
> > 
> > My understanding is that the URN should be transmitted in the 180
> > ringing after the forwarded call has reached ist final 
> destination and
> > the phone is ringing at the UE, not in the 181 sent by the 
> forwarding
> > proxy when it decides to to forward the call. Also the RFC 3261 only
> > allows Alert-Info in 180 responses. Or did I miss something here?
> 
> I checked, and you are right that A-I isn't allowed in 181. 
> Sorry about 
> that. But it seems like a mistake to me.
> 
> The behavior you describe requires there to be a stateful 
> agent in the 
> network that is aware this has happened. In general there may 
> be nothing 
> in a position to perform that role. But in any case it is a nit.

It's true, only a statefull proxy is able to insert this URN if it is
send in 180 ringing. 
But this is the scenario for which this particular A-I URN is defined. 

The caller's UA renders a ringback 
tone when it receives the 180, not earlier. The URN should tell the the
caller's UA to render 
a specific ringback *instead* of the ringback used for not forwarded
calls. 
In principle the 181 tells the caller's UA that the call has been
forwarded and the UA may decide, 
independent from the proxy, to notity the caller about this. 

But this was my personal opinion and this one of Alan's use cases. 
I am not sure he follows the discussion, so let me check with him. 

Thank you
Laura

> 
> 	Thanks,
> 	Paul
> 
> > Thanks a lot
> > Laura
> > 
> >> 	Thanks,
> >> 	Paul
> >>
> >> [e-mail] wrote:
> >>>  
> >>> Hi,
> >>>
> >>> We've re-submitted the Alert-Info URNs draft for DISPATCH
> >>>
> >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert
> >> -info-urns
> >>> -00.txt . (The previous version od the draft was in BLISS 
> >> and we had a
> >>> presentation in BLISS at the last IETF.)
> >>>
> >>> We did some major changes, as suggested on the mailing list, e.g.:
> >>>  Added:  
> >>>   - Description of the interoperability problems for 
> >> PBX-services (in
> >>> the Introduction chapter) 
> >>>   - Requirements for the Alert-Info URNs mechanism 
> >>>   - Alert-Info URNs Indications for country-specific tones
> >>>  Changed: 
> >>>   - Initial IANA Registration mechanism to avoid 
> >> combinatorial explosion
> >>> of IANA values. 
> >>>
> >>>
> >>> Many thanks for the comments and suggestions,
> >>> Laura 
> >>>
> >>>
> >>>
> >>>     
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail]
> >>> [mailto:[e-mail]] On Behalf Of
> >>> [e-mail]
> >>> Sent: Monday, October 19, 2009 1:00 PM
> >>> To: [e-mail]
> >>> Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt 
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>> directories.
> >>>
> >>> 	Title           : Alert-Info URNs for the Session Initiation
> >>> Protocol (SIP)
> >>> 	Author(s)       : D. Alexeitsev, et al.
> >>> 	Filename        : draft-liess-dispatch-alert-info-urns-00.txt
> >>> 	Pages           : 25
> >>> 	Date            : 2009-10-19
> >>>
> >>> The Session Initiation Protocol (SIP) supports the capability to
> >>> provide a reference to the alternative ringback tone (RBT) for
> >>> caller, or ring tone (RT) for callee using the Alert-Info header.
> >>> However, the reference addresses only the network resources with
> >>> specific rendering properties.  There is currently no support for
> >>> predefined standard identifiers for ringback tones or semantic
> >>> indications without tied rendering.  To overcome this 
> >> limitations and
> >>> support new applications a family of the URNs is defined in this
> >>> specification.
> >>>
> >>> A URL for this Internet-Draft is:
> >>>
> >> http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert
> >> -info-urns
> >>> -00.txt
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> Below is the data which will enable a MIME compliant mail reader
> >>> implementation to automatically retrieve the ASCII version of the
> >>> Internet-Draft.
> >>> _______________________________________________
> >>> dispatch mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dispatch
> >>>
> > 
>