Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

[Paul Kyzivat <[e-mail]>]

I think the choices of where to carry the reason (header, or uri 
parameter), and how reasons are named, are independent decisions.

I think I understand why the uri parameter approach is being suggested, 
and it does have some benefits. But it has some drawbacks as well. I'm 
not yet settled on my final conclusion about them.

One issue with the uri parameter approach is: what if the new target is 
not a sip-uri? It could easily be a tel: uri - there are quite 
reasonable use cases for that. It could also potentially be an IM: or 
PRES: uri. And in the case of 3xx responses it can be any kind of URI - 
even http. At best the rules for affixing parameters can vary by URI 
scheme, and at worst some schemes may not allow it.

	Paul

Dolly, Martin C, ALABS wrote:
> Hello,
> 
> The use of the URI parameter allows for backward compatiblity with existing devices/UAs. They will take what is in the contact header of the 3xx message and just use it the the R-URI of the outgoing INVITE.
> 
> I see compliant devices/UAs using both the URI parameter and History-Info moving forward.
> 
> I agree that either the Reason header or URI parameter could work, but prefer the URI parameter because of the backward compatibility with existing devices.
> 
> Cheers,
> 
> Martin
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of Elwell, John
>>Sent: Tuesday, October 11, 2005 7:54 AM
>>To: GARCIN Sebastien RD-CORE-ISS; Paul Kyzivat
>>Cc: sipping
>>Subject: RE: [Sipping] Re:
>>draft-elwell-sipping-service-retargeting-00.txt
>>
>>
>>Sebastien,
>>
>>Personally I don't have a problem with using the Q.732.2 
>>namespace. Whether
>>this is for the Reason header or a URI parameter should be 
>>determined based
>>on discussion of which is the preferred mechanism. The authors of the
>>service-retargeting draft had reasons for preferring the 
>>mechanism in that
>>draft (see section 13.1). Of these reasons, in my opinion the 
>>first is the
>>most important.
>>
>>John
>> 
>>
>>
>>>-----Original Message-----
>>>From: GARCIN Sebastien RD-CORE-ISS 
>>>[mailto:[e-mail]] 
>>>Sent: 11 October 2005 12:22
>>>To: Paul Kyzivat; Elwell, John
>>>Cc: sipping
>>>Subject: RE: [Sipping] Re: 
>>>draft-elwell-sipping-service-retargeting-00.txt
>>>
>>>Hi Paul, John,
>>>
>>>It seems from the discussion below that a possible agreable 
>>>way forwards is to define a new ITU-T Q.732.2 namespace for 
>>>the Reason header. I think it quite reasonable to do so.
>>>
>>>Has anybody got any problem with that approach ?
>>>
>>>Regards
>>>sebastien
>>>
>>> 
>>>
>>>-----Message d'origine-----
>>>De : [e-mail] 
>>>[mailto:[e-mail]] De la part de Paul Kyzivat
>>>Envoyé : mardi 11 octobre 2005 00:07
>>>À : Elwell, John
>>>Cc : sipping
>>>Objet : Re: [Sipping] Re: 
>>>draft-elwell-sipping-service-retargeting-00.txt
>>>
>>>John,
>>>
>>>Thanks for hearing me out. More inline.
>>>
>>>	Paul
>>>
>>>Elwell, John wrote:
>>>
>>>>Paul,
>>>>
>>>>In-line,
>>>>
>>>>John
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Paul Kyzivat [mailto:[e-mail]]
>>>>>Sent: 10 October 2005 15:27
>>>>>To: Elwell, John
>>>>>Cc: sipping
>>>>>Subject: Re: [Sipping] Re: 
>>>>>draft-elwell-sipping-service-retargeting-00.txt
>>>>>
>>>>>Before commenting further, I've had some offline feedback that my 
>>>>>earlier comments were bonkers or out-of-line in some way. 
>>>
>>>If anybody 
>>>
>>>>>feels that way, feel free to yell at me here. (You won't hurt my 
>>>>>feelings.)
>>>>>
>>>>>In any case, I have been thinking about this further. My 
>>
>>most major 
>>
>>>>>problem with this, and all the similar proposals that 
>>
>>have predated 
>>
>>>>>it, is that I don't find the formulation of the reasons 
>>
>>to be well 
>>
>>>>>motivated or defined. They just seem to be a selection of a few 
>>>>>arbitrary reasons among many other possibilities. And even 
>>>
>>>then there 
>>>
>>>>>is insufficient definition to allow me to decide, in particular 
>>>>>routing cases, which reason, if any, applies.
>>>>>
>>>>>It finally struck me that these reasons can be understood 
>>
>>as simply 
>>
>>>>>being specified by traditional telephony *features*, as 
>>
>>defined by 
>>
>>>>>Telcordia. In that context, everything makes sense - there 
>>>
>>>is a clear 
>>>
>>>>>and precise definition of each reason - the definition of the 
>>>>>corresponding feature.
>>>>>
>>>>>If viewed in that light, this exercise becomes somewhat 
>>
>>different. 
>>
>>>>>IETF doesn't define features, so it shouldn't be defining 
>>>
>>>retargetting 
>>>
>>>>>reasons either. It might provide a mechanism to transport 
>>>
>>>reasons, but 
>>>
>>>>>the mechanism would need to reference reasons in an 
>>>
>>>externally defined 
>>>
>>>>>namespace. (Note we already have that with the Reason header.)
>>>>
>>>>[JRE] That would be another approach, but I got the 
>>
>>impression from 
>>
>>>>some people that they would prefer to see a SIP solution - 
>>>
>>>something 
>>>
>>>>that could also be used outside the context of PSTN 
>>>
>>>interworking - and 
>>>
>>>>hence the attempt to try to define SIP service reasons.
>>>
>>>I think in general people something general over something 
>>>less general.
>>>
>>>But we need to determine if the wish is well defined and 
>>>achievable within what is considered to be the scope of IETF.
>>>
>>>In particular the key requirement is to define the *reason* 
>>>for retargetting, and if (as I conjecture) the kinds of 
>>>reasons being sought can only be expressed in terms of 
>>>features, and if ietf doesn't want to define features, then I 
>>>don't think this is achievable generically.
>>>
>>>Possibly there is a compromise position - where certain 
>>>reasons are defined that are well defined in terms of basic 
>>>sip routing concepts, and other reasons can be defined 
>>>independently, as different namespaces, by other groups. And 
>>>then reasons from any such namespace can be used. 
>>>(Note we already have essentially that with the Reason header.)
>>>
>>>The problem with this is, of course, that there is plenty of 
>>>opportunity to receive reasons that are not understood. This 
>>>is not a good state of affairs. But maybe it is the best that 
>>>can be achieved.
>>>
>>>
>>>>I guess what this thread needs
>>>>to solve is:
>>>>1. Is there a problem that needs solving? A number of 
>>>
>>>people believe 
>>>
>>>>there is, but not everybody.
>>>
>>>I for one agree that there is *some* problem, or perhaps 
>>>several problems. At the least there are:
>>>- getting to the "proper" VM server and mailbox
>>>- getting the VM server to take the "proper" action
>>>- a PSTN interop problem
>>>(I suspect there are others but can't name them right now.)
>>>
>>>Whether something like H-I and redirection reason is the best 
>>>way to solve those problems is a whole different question.
>>>
>>>I do get the impression that I am in the distinct minority, 
>>>and that many people do feel that redirection reason is an ok 
>>>way to solve these problems.
>>>
>>>My feeling is that if it can't address the scenario with two 
>>>VM servers then it is a bad solution *for IETF*. If may still 
>>>be an acceptable solution for a controlled environment.
>>>
>>>
>>>>2. Should it be solved by a new namespace within SIP or by 
>>>
>>>referencing 
>>>
>>>>an existing PSTN-related namespace (e.g., ITU-T recommendation 
>>>>Q.732.2, which I believe is what the Telcordia 
>>>
>>>specification is based on)?
>>>
>>>I'm trying to keep an open mind here, but I'm not seeing how 
>>>we can define a namespace within sip that meaningfully and 
>>>adequately defines reasons, but doesn't require a sip 
>>>specification of features, and that covers the cases desired 
>>>by the proponents so far.
>>>
>>>So I think we are stuck with either the defining sip reasons 
>>>in terms of basic sip routing behavior and error codes, or 
>>>referencing namespaces defined elsewhere. In the latter case 
>>>there is then the need to define when these codes apply in 
>>>terms of a sip implementation, which probably means 
>>>specifying part of a sip implementation.
>>>
>>>
>>>>3. The mechanism - that described in the earlier 
>>
>>redirection-reason 
>>
>>>>(still
>>>>current) or that described in the present draft, which was 
>>>
>>>written to 
>>>
>>>>get around some criticisms of the redirection reason draft.
>>>
>>>>I think there is also a body of opinion - I am not sure 
>>
>>how large - 
>>
>>>>that we need to solve the problem, but the namespace used 
>>>
>>>(as long as 
>>>
>>>>it has a repertoire suitable for PSTN mapping as a 
>>
>>minimum) and the 
>>
>>>>mechanism are secondary.
>>>>
>>>>
>>>>
>>>>>This would not however facilitate the interoperation between 
>>>>>environments that have differing notions of features.
>>>>
>>>>JRE] No, perhaps not, but it would at least permit 
>>>
>>>interoperation in 
>>>
>>>>some cases where interoperation is less than satisfactory 
>>>
>>>at present.
>>>
>>>Sadly, perhaps it is the best that can be hoped for.
>>>
>>>	Paul
>>>
>>>
>>>
>>>>>	Paul
>>>>>
>>>>>Elwell, John wrote:
>>>>>
>>>>>
>>>>>>Paul,
>>>>>>
>>>>>>Thanks for your comments. See below.
>>>>>>
>>>>>>John
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Paul Kyzivat [mailto:[e-mail]]
>>>>>>>Sent: 07 October 2005 23:41
>>>>>>>To: sipping
>>>>>>>Subject: [Sipping] Re: 
>>>>>
>>>>>draft-elwell-sipping-service-retargeting-00.txt
>>>>>
>>>>>
>>>>>>>John,
>>>>>>>
>>>>>>>I was commenting on the draft, and when I got to the end 
>>>
>>>I was then 
>>>
>>>>>>>ready to make an observation. But I think it makes more 
>>>
>>>sense to put 
>>>
>>>>>>>the observation first, and then let the specific 
>>
>>comments follow. 
>>
>>>>>>>The observation in not solely in response to *this* 
>>>
>>>draft. It is in 
>>>
>>>>>>>response to the whole series of things that preceded it 
>>
>>as well - 
>>
>>>>>>>Diversion, History-Info, and others whose names escape me.
>>>>>>>
>>>>>>>	Paul
>>>>>>>
>>>>>>>I think we are discussing requirements at the wrong level. 
>>>>>
>>>>>I suspect 
>>>>>
>>>>>
>>>>>>>there are in reality only a few reasons why anybody cares about 
>>>>>>>retargetting. (E.g. the message played by a voicemail 
>>>>>>>server.) It would 
>>>>>>>perhaps be more fruitful to discuss those things rather that 
>>>>>>>to assume 
>>>>>>>that the solution for those is to have access to 
>>>
>>>retargetting info.
>>>
>>>>>>[JRE] Good point. I have only hinted at this in the 
>>>>>
>>>>>Introduction section,
>>>>>
>>>>>
>>>>>>e.g., "When a  request is service retargeted to a voice 
>>>>>
>>>>>mail server the
>>>>>
>>>>>
>>>>>>voice mail server is likely to need to know the identity of 
>>>>>
>>>>>the original
>>>>>
>>>>>
>>>>>>target in order to access the correct mailbox and the 
>>>>>
>>>>>reason for service
>>>>>
>>>>>
>>>>>>retargeting in order to behave appropriately, e.g., play an 
>>>>>
>>>>>appropriate
>>>>>
>>>>>
>>>>>>announcement." A next version could have a little more 
>>>
>>>text on this.
>>>
>>>>>>
>>>>>>
>>>>>>>Now more specific comments on this draft:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Retargeting is a normal part of routing a request in 
>>
>>SIP. For 
>>
>>>>>>>> example, an outbound proxy might convert the initial 
>>>>>>>
>>>>>>>Request-URI from 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> a telephone URI (perhaps in the form of a dial string) 
>>>>>>>
>>>>>>>to a SIP URI. 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> As another example, the final proxy typically replaces 
>>>>>>>
>>>>>>>an Address of 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Record with the URI of a registered contact. 
>>>>>>>
>>>>>>>I continue to struggle with the distinction between "normal" 
>>>>>>>(uninteresting) retargetting, and the kind of retargetting 
>>>>>>>you find of 
>>>>>>>interest.
>>>>>>>
>>>>>>>I suspect that what is interesting depends on who is asking, 
>>>>>>>not who is 
>>>>>>>telling. The implication here is that the translation from an 
>>>>>>>AOR to a 
>>>>>>>registered contact is "normal" and uninteresting. But a 
>>>>>>>voicemail server 
>>>>>>>could be registered. In that case is the translation no 
>>>>>
>>>>>longer normal?
>>>>>
>>>>>
>>>>>>[JRE] In this case the proxy is translating an AoR into a 
>>>>>
>>>>>contact URI
>>>>>
>>>>>
>>>>>>registered against that AoR, and hopefully the UAS will 
>>>>>
>>>>>know, when receiving
>>>>>
>>>>>
>>>>>>a request to that contact URI, that has indeed been 
>>>>>
>>>>>retargeted from the AoR
>>>>>
>>>>>
>>>>>>concerned.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> As a further example, service retargeting information 
>>>>>>>
>>>>>>>can be of use 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> to a voice mail server. When a  request is service 
>>>>>>>
>>>>>>>retargeted to a 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> voice mail server the voice mail server is likely to 
>>>>>>>
>>>>>>>need to know the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> identity of the original target in order to access 
>>
>>the correct 
>>
>>>>>>>> mailbox and the reason for service retargeting in order 
>>>>>>>
>>>>>>>to behave 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> appropriately, e.g., play an appropriate announcement. 
>>>>>>>
>>>>>>>The implication that the vm server would have to look at 
>>>>>>>anything other 
>>>>>>>than the R-URI to figure out what mailbox to use is 
>>>>>>>distressing to me. 
>>>>>>>It implies that the entity doing the retargetting wasn't 
>>>
>>>precise in 
>>>
>>>>>>>specifying the target. If not, this server might not have 
>>>>>>>access to the 
>>>>>>>right mailbox.
>>>>>>
>>>>>>[JRE] Consider the case where an original request to A 
>>
>>gets service
>>
>>>>>>retargeted to B for some reason, perhaps still within the 
>>>>>
>>>>>context of the
>>>>>
>>>>>
>>>>>>same enterprise. If B is also not available, it needs to 
>>>>>
>>>>>retarget to the
>>>>>
>>>>>
>>>>>>enterprise voice mail server. It might be the original 
>>>>>
>>>>>destination A that
>>>>>
>>>>>
>>>>>>should determine the particular mailbox, but proxy B does 
>>>>>
>>>>>not have the means
>>>>>
>>>>>
>>>>>>to insert this information. It would be good if the voice 
>>>>>
>>>>>mail server could
>>>>>
>>>>>
>>>>>>deduce, from history-info within the request, that the 
>>>>>
>>>>>original target was A
>>>>>
>>>>>
>>>>>>and the reason for retargeting was (whatever).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I am somewhat more sympathetic to using huristics applied 
>>>
>>>to known 
>>>
>>>>>>>attributes of the call in order to decide how to respond. 
>>>>>
>>>>>However, I 
>>>>>
>>>>>
>>>>>>>still think in general it makes better sense for the element 
>>>>>>>doing the 
>>>>>>>retargetting to the VM server to explicitly decide what kind of 
>>>>>>>treatment is required, and inform the VM server of that, 
>>>>>
>>>>>rather than 
>>>>>
>>>>>
>>>>>>>having it guess.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - [HIST] reports all retargets, not just service 
>>>>>>>
>>>>>>>retargets. This puts 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> the burden on the UAS or UAC to pick out which 
>>>>>
>>>>>retargets are for 
>>>>>
>>>>>
>>>>>>>> service reasons and which are for normal SIP routing 
>>
>>reasons. 
>>
>>>>>>>I agree with this criticism of H-I. But paring down the 
>>
>>amount of 
>>
>>>>>>>history info to just what you think is needed doesn't seem 
>>>>>>>better to me, 
>>>>>>>it might even be worse. It assumes that you know what 
>>>>>
>>>>>information is 
>>>>>
>>>>>
>>>>>>>important to others, without even knowing who those others 
>>>>>>>are. It also 
>>>>>>>constrains you to information about what has happened, not your 
>>>>>>>inferences about that that implies.
>>>>>>
>>>>>>[JRE] The draft does not propose that we suppress some of 
>>>>>
>>>>>the history-info.
>>>>>
>>>>>
>>>>>>It merely proposes that we be able to augment it in certain 
>>>>>
>>>>>circumstances.
>>>>>
>>>>>
>>>>>>>> REQ-4. It must be possible to indicate that the reason for 
>>>>>>>> retargeting is because there are no registered contacts 
>>>>>>>
>>>>>>>for the URI. 
>>>>>>>
>>>>>>>None registered? Or none registered that the callee is 
>>>>>>>willing to offer 
>>>>>>>the call to? Or is that a different reason?
>>>>>>
>>>>>>[JRE] I think the latter. For example, if caller prefs 
>>
>>indicated a
>>
>>>>>>preference for video and there are no video-capable 
>>>>>
>>>>>contacts registered, it
>>>>>
>>>>>
>>>>>>would treat it as no registered contacts.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> REQ-5. It must be possible to indicate that the reason for 
>>>>>>>> retargeting is because contacts for the URI are busy. 
>>>>>>>
>>>>>>>Busy is a difficult concept to nail down. If a user has 
>>>>>
>>>>>call waiting, 
>>>>>
>>>>>
>>>>>>>but decides not to pick up a 2nd call because he is too 
>>>>>
>>>>>occupied with 
>>>>>
>>>>>
>>>>>>>the first call, is that a Busy, or a No Answer?
>>>>>>
>>>>>>[JRE] If is up to the proxy or redirect to determine when 
>>>>>
>>>>>it reports busy,
>>>>>
>>>>>
>>>>>>but I agree we could have some more words discussing these cases.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>If there are two contacts to try, and one is Busy, and the 
>>>>>>>other can't 
>>>>>>>support the requested call type, is the reason for 
>>>>>>>retargetting because 
>>>>>>>of Busy?
>>>>>>>
>>>>>>>In general, multiple of these reasons could hold for a given 
>>>>>>>retargetting.
>>>>>>
>>>>>>JRE] In theory, but in practice there is normally one 
>>>
>>>condition that
>>>
>>>>>>triggers the retargeting. So if there is only one contact 
>>>>>
>>>>>that can accept
>>>>>
>>>>>
>>>>>>the requested call type and that is busy, I imagine the 
>>
>>reason for
>>
>>>>>>retargeting would be busy - there is a compatible contact, 
>>>>>
>>>>>it is just that
>>>>>
>>>>>
>>>>>>it is busy. It might be possible to give multiple reasons, 
>>>>>
>>>>>but I am not
>>>>>
>>>>>
>>>>>>convinced there are compelling reasons to do so.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> REQ-6. It must be possible to indicate that the reason for 
>>>>>>>> retargeting is because the request was not answered 
>>
>>during the 
>>
>>>>>>>> alerting period. 
>>>>>>>
>>>>>>>Suppose there are several registered contacts, but routing is 
>>>>>>>via serial 
>>>>>>>forking. Then is the second a retargetting because the 
>>>>>
>>>>>first contact 
>>>>>
>>>>>
>>>>>>>didn't answer during the alerting period?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> The solution here adopts the principles of [SRVCTRL] 
>>>>>
>>>>>and defines 
>>>>>
>>>>>
>>>>>>>> parameter names and values for indicating retargeting 
>>>>>>>
>>>>>>>details to a 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> service or application.  
>>>>>>>
>>>>>>>I find a significant difference. In RFC3087, when URIs are 
>>>>>
>>>>>populated 
>>>>>
>>>>>
>>>>>>>with parameters, the use of those parameters is by 
>>>>>>>prearrangement with 
>>>>>>>the targetted resource - it is expecting the parameters.
>>>>>>
>>>>>>[JRE] That wasn't my understanding of RFC3087 - I don't 
>>>>>
>>>>>think it is explicit
>>>>>
>>>>>
>>>>>>on this.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Here, it seems that you are popping parameters on to 
>>
>>any old URI, 
>>
>>>>>>>regardless of whether the owner/creator of that URI 
>>>>>>>wanted/expected that 
>>>>>>>to happen or not.
>>>>>>>
>>>>>>>I foresee this potentially breaking lots of things. While I 
>>>>>>>don't have 
>>>>>>>anything specific in mind, in general it is a bad idea to 
>>>>>>>mess with URIs 
>>>>>>>that don't belong to you.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> When a request is service retargeted (for a reason 
>>>>>>>
>>>>>>>meaningful to a 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> retargeted-to user or application), two parameters are 
>>>>>>>
>>>>>>>added to the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> retargeted-to URI: the old-target parameter contains the 
>>>>>>>
>>>>>>>previous 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> target URI and the retargeting-reason parameter contains 
>>>>>>>
>>>>>>>the reason 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> for service retargeting. Provided this is the last 
>>>>>>>
>>>>>>>retarget, these 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> parameters will reach the UAS and can be provided to 
>>>>>
>>>>>the user or 
>>>>>
>>>>>
>>>>>>>> application. 
>>>>>>>
>>>>>>>And if the request is redirected multiple times, these 
>>>>>>>parameters keep 
>>>>>>>getting nested deeper and deeper?
>>>>>>>
>>>>>>>E.g. Alice calls Bob who forwards to Carol who forwards to Ted.
>>>>>>>
>>>>>>>     sip:[e-mail]; \
>>>>>>>        old-target=sip:[e-mail];user=phone; \
>>>>>>>          old-target=sip:[e-mail];user=phone; \
>>>>>>>            old-target=sip:[e-mail];user=phone; \
>>>>>>>            retargeting-reason=busy; \
>>>>>>>          retargeting-reason=busy; \
>>>>>>>        retargeting-reason=busy
>>>>>>
>>>>>>[JRE] No, but each URI that gets added to History-Info 
>>>>>
>>>>>would potentially
>>>>>
>>>>>
>>>>>>have its own old-target and retargeting-reason parameters.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>(which has some escaping problems to be dealt with too.)
>>>>>>>
>>>>>>>	Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Sipping mailing list  
>>>
>>>https://www1.ietf.org/mailman/listinfo/sipping
>>>
>>>>>>>This list is for NEW development of the application of SIP
>>>>>>>Use [e-mail] for questions on 
>>
>>current sip
>>
>>>>>>>Use [e-mail] for new developments of core SIP
>>>>>>>
>>>>>>
>>>>>>
>>>_______________________________________________
>>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>This list is for NEW development of the application of SIP
>>>Use [e-mail] for questions on current sip
>>>Use [e-mail] for new developments of core SIP
>>>
>>
>>_______________________________________________
>>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>This list is for NEW development of the application of SIP
>>Use [e-mail] for questions on current sip
>>Use [e-mail] for new developments of core SIP
>>
> 
> 

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