Re: [sipcore] draft-ietf-sipcore-location-conveyance-04

["James M. Polk" <[e-mail]>]

At 08:04 AM 10/29/2010, Paul Kyzivat wrote:
>Its unclear to me how many people have opinions on this.

what's clear to me is people want fixed what is not subjective, i.e., 
the ABNF. From that, we do need to determine which of the 5 proposals 
you put out is the way forward.

>It certainly can be one of the discussion points.
>If you like, I can make up some slides on the alternatives for use 
>at the meeting.
>
>But it will be good if we can reduce the number of alternatives 
>between now and then. ISTM there are basically two decisions to make 
>about the syntax:
>
>- at most two URIs, or an unlimited number
>- routing-param part of same header, or a separate header

I agree with distilling it down to these two points wrt to the syntax.

The first point is fairly easy (I think) if we're focused on 
addressing that one (at a time).

The second point you bring up is very new (i.e., the idea of separate 
headers for these two indications). Once we focus on that idea, I 
think we can come to a conclusion without much difficulty.

A third (multipart) point to bring up is related to the first point, 
if there are multiple URIs,

   3a - do all recipients have to implement one or both URI scheme 
sets (i.e., SIP-based and HTTP-based), or just to one mandatory (and 
one should or may), or do we not mandate anything here (which has 
interoperability and effective communications implications).

   3b - aside from independent of 3a, do we specify a specific error 
code for "URI scheme not supported, send (a specific) other URI scheme".

3b is exactly what John Elwell and I have been discussing, and 
involves 5 new, very specific 4XX level errors with really no room 
for misinterpretation:

 > 401 "URI scheme not supported - send SIP:URI"
 > 402 "URI scheme not supported - send SIPS:URI"
 > 403 "URI scheme not supported - send PRES:URI"
 > 404 "URI scheme not supported - send HTTP:URI"
 > 405 "URI scheme not supported - send HTTPS:URI"

I know my coauthor will hyperventilate on this possibility because he 
wants as few error codes as is possible, but I think these are rather 
hard to argue against due to their specific meaning, and their 
actionable result (

   - the UAC either sends a new SIP request with the requested
     URI scheme, or location isn't sent because that URI scheme
     isn't available to send).

The UAC knows exactly what to do with this error, and if it doesn't 
send a location URI in the subsequent request, the UAS knows that URI 
scheme wasn't in the UAC to send.

If the UAC can send the requested URI scheme, all's fine.

The UAC can also make the choice to send a PIDF-LO (if it can) as a fall-back.



>The first of those is a real functionality discussion.
>(Or a computer science discussion of whether there is a number 
>bigger than one other than "many".)
>
>The second is partly esthetic, and partly a technical issue for 
>those writing sip parsers. Making it all one header causes it to be 
>a one-off from a parser perspective.

I wish I knew more about this during the RFC 5606 debate, as that doc 
would have said something about necessitating a new SIP header to 
accomplish what it suggested, and we wouldn't be getting into this 
topic so (stickin`) late in the game.

That said, location-conveyance is still an ID, so it's changeable- if 
we have consensus that's what's best.

I think it might not be so hard to include this new header, as it'll 
have a rule that if an LR receives a SIP request with a SIP 
Geolocation header, that LR MUST look for and obey the policy flag 
set by the Geolocation-routing header value (or whatever we call the header).

James


>         Thanks,
>         Paul
>
>On 10/28/2010 8:51 PM, James M. Polk wrote:
>>At 05:38 AM 10/28/2010, Elwell, John wrote:
>>>Yes, 4 looks good, but I could live with 1.
>>
>>I think this has become #1 of two major open issues to address in
>>Beijing (along with the supported and unsupported URI schemes and their
>>respective possible error codes, as 2a and 2b).
>>
>>James
>>
>>
>>>John
>>>
>>> > -----Original Message-----
>>> > From: [e-mail]
>>> > [mailto:[e-mail]] On Behalf Of Anders Kristensen
>>> > Sent: 28 October 2010 05:53
>>> > To: [e-mail]
>>> > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-04
>>> >
>>> > I haven't really followed the discussion closely but I'll say this
>>> > anyway. Many header fields are of a form similar to Geolocation,
>>> > essentially lists of URI, and allow for parameters. But I think the
>>> > parameters are pretty much always associated with individual
>>> > entries in
>>> > the list and may be present for more than one.
>>> >
>>> > From what I can tell, in the case of Geolocation, the
>>> > routing-allowed
>>> > param is not really attached to any particular entry in the list
>>> > suggesting that maybe it doesn't belong in the same header field. I
>>> > think that's the thinking that lead Paul to options 4 or 5 which seem
>>> > much preferable to me. That allows Geolocation to fit the text in RFC
>>> > 3261 that talks about combining header fields:
>>> >
>>> > Specifically, any SIP
>>> > header whose grammar is of the form
>>> >
>>> > header = "header-name" HCOLON header-value *(COMMA
>>> > header-value)
>>> >
>>> > allows for combining header fields of the same name into a comma-
>>> > separated list.
>>> >
>>> > Granted, there's no rule that says that header fields with
>>> > comma-separated values *must* fit the above grammar but ISTM
>>> > that it's a
>>> > pretty established pattern which is worth observing.
>>> >
>>> > Thanks,
>>> > Anders
>>> >
>>> > On 10/27/2010 9:10 PM, James M. Polk wrote:
>>> > > At 06:50 PM 10/27/2010, Paul Kyzivat wrote:
>>> > >> I have a bunch inline here.
>>> > >
>>> > > I'll say ;-)
>>> > >
>>> > >> This supersedes my earlier suggested ABNF change.
>>> > >
>>> > > ack
>>> > >
>>> > >
>>> > >> On 10/27/2010 2:32 PM, James M. Polk wrote:
>>> > >>> Paul
>>> > >>>
>>> > >>> in-line
>>> > >>>
>>> > >>> At 08:36 PM 10/26/2010, Paul Kyzivat wrote:
>>> > >>>> I took a quick look at the new version, and it seems to
>>> > have cleanup a
>>> > >>>> lot. But there *still* seems to be a problem with the syntax.
>>> > >>>> (Interplay between ABNF and text.) From the text, I find:
>>> > >>>>
>>> > >>>> The placement of the "routing-allowed" header field parameter,
>>> > >>>> strongly encouraged by [RFC5606], is outside the
>>> > locationValue, and
>>> > >>>> MUST always be last in the header field value. The
>>> > routing-allowed
>>> > >>>> parameter MUST be present, even when no locationValue is present.
>>> > >>>>
>>> > >>>> This is questionably supported by the ABNF:
>>> > >>>>
>>> > >>>> Geolocation-header = "Geolocation" HCOLON Geolocation-value
>>> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] )
>>> > >>>> / routing-param
>>> > >>>
>>> > >>> the above, I believe - but am open to be corrected by
>>> > those better at
>>> > >>> ABNF syntax that I, says
>>> > >>>
>>> > >>> - the Geolocation header can optionally have one or more
>>> > locationValues
>>> > >>> - which are where the location URIs go
>>> > >>
>>> > >> The above says *a* Geolocation header can have
>>> > >> - one or two locationValues
>>> > >> - OR one routing-param
>>> > >>
>>> > >> (The slash means OR)
>>> > >>
>>> > >> But it doesn't state that the Geolocation header itself can appear
>>> > >> only once. And obviously if the goal is to have a
>>> > locationValue AND a
>>> > >> routing-param in the message, then with the above syntax
>>> > at least TWO
>>> > >> Geolocation headers will be required.
>>> > >>
>>> > >>> - but that the Geolocation header *will* have a routing-param
>>> > >>> - which is the "routing-allowed" paramter that RFC 5606
>>> > wanted included
>>> > >>
>>> > >> Since the slash means OR, it doesn't mean it *will*.
>>> > >>
>>> > >>> The text of the ID then says that only zero, one or two
>>> > locationValues
>>> > >>> are allowed, which we all agreed to in Maastricht (in SIPCORE and
>>> > >>> ECRIT/GEOPRIV).
>>> > >>>
>>> > >>>> locationValue = LAQUOT locationURI RAQUOT
>>> > >>>> *(SEMI geoloc-param)
>>> > >>>> locationURI = sip-URI / sips-URI / pres-URI
>>> > >>>> / http-URI / HTTPS-URI
>>> > >>>> / cid-url ; (from RFC 2392)
>>> > >>>> / absoluteURI ; (from RFC 3261)
>>> > >>>> geoloc-param = generic-param; (from RFC 3261)
>>> > >>>> routing-param = "routing-allowed" EQUAL "yes" / "no"
>>> > >>>>
>>> > >>>> It only works if you presume that there are separate
>>> > occurrences of
>>> > >>>> GeoLocation-header in the message, one with just
>>> > locations, another
>>> > >>>> with just the routing-param.
>>> > >>>
>>> > >>> I don't get that part of your point, but I guess Martin's
>>> > next message
>>> > >>> says I need to add a "COMMA" after the ']' but before the
>>> > ')'. Would
>>> > >>> this satisfy your issue?
>>> > >>
>>> > >> Adding the COMMA and removing the slash would require the
>>> > >> routing-param, and would separate it from the
>>> > location-value. But then
>>> > >> if you only wanted the routing-param without any locationValues you
>>> > >> would have to write:
>>> > >>
>>> > >> Geolocation:,routing-allowed=no
>>> > >>
>>> > >> which is at least a bit weird, which I think is what Martin meant.
>>> > >>
>>> > >>>> The routing-param certainly can't be "last in the header
>>> > field value"
>>> > >>>> except in the degenerate sense, since it must be first
>>> > and only in a
>>> > >>>> Geolocation-header.
>>> > >>>
>>> > >>> If the routing-param was intended to be first, wouldn't
>>> > it appear first
>>> > >>> on this line?
>>> > >>
>>> > >> My point was that the syntax as written only allows
>>> > routing-param by
>>> > >> itself in a geolocation-header. E.g.
>>> > >>
>>> > >> Geolocation:routing-allowed=no
>>> > >>
>>> > >> It can't share a single Geolocation header with a
>>> > locationValue. Hence
>>> > >> it is *both* first and last in that header.
>>> > >>
>>> > >>>> Geolocation-value = ( locationValue [ COMMA locationValue ] )
>>> > >>>> / routing-param
>>> > >>>
>>> > >>> but it doesn't, so I'm confused.
>>> > >>
>>> > >> Again, the slash means OR. So you have:
>>> > >>
>>> > >> Geolocation-value = ( locationValue [ COMMA locationValue ] )
>>> > >> OR
>>> > >> Geolocation-value = routing-param
>>> > >>
>>> > >> (Though you can't write it that way in ABNF.
>>> > >>
>>> > >>>> Below are some specific cases - both valid and invalid.
>>> > In each case I
>>> > >>>> show some headers bracketed by "...". That is intended
>>> > to mean other
>>> > >>>> headers in a message, but all in the same message. (And
>>> > when I show
>>> > >>>> multiple headers, there could be other non-geoloc
>>> > headers interleaved.)
>>> > >>>>
>>> > >>>> * The following are legal according to the above, and
>>> > probably within
>>> > >>>> expected usage:
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: cid:[e-mail]
>>> > >>>> Geolocation: routing-allowed=yes
>>> > >>>> ...
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: cid:[e-mail],cid:[e-mail]
>>> > >>>> Geolocation: routing-allowed=yes
>>> > >>>> ...
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: routing-allowed=no
>>> > >>>> ...
>>> > >>>>
>>> > >>>> * IIUC the following are allowed by the above both
>>> > syntactically and
>>> > >>>> according to the text, but is presumably not *intended*
>>> > to be valid.
>>> > >>>> (Its legal because the in each instance of Geolocation-header its
>>> > >>>> last.)
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: routing-allowed=no
>>> > >>>> Geolocation: routing-allowed=yes
>>> > >>>> ...
>>> > >>>>
>>> > >>>> The following is also allowed - I don't know if its
>>> > intended or not:
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: routing-allowed=yes
>>> > >>>> Geolocation: cid:[e-mail],cid:[e-mail]
>>> > >>>> ...
>>> > >>>>
>>> > >>>> * The following is allowed by the ABNF though disallowed
>>> > by the text:
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: cid:[e-mail],cid:[e-mail]
>>> > >>>> Geolocation: cid:[e-mail]
>>> > >>>> ...
>>> > >>>>
>>> > >>>> * The following is *not* allowed by the ABNF. I suspect
>>> > it might be
>>> > >>>> intended to be valid, but I'm far from sure about it:
>>> > >>>>
>>> > >>>> ...
>>> > >>>> Geolocation: cid:[e-mail],routing-allowed=yes
>>> > >>>> ...
>>> > >>>
>>> > >>> to get this above example "allowed", would I correct the
>>> > existing ABNF
>>> > >>> to be
>>> > >>>
>>> > >>>> Geolocation-value = ( locationValue [ COMMA
>>> > locationValue ] COMMA )
>>> > >>>> / routing-param
>>> > >>>
>>> > >>> ?
>>> > >>
>>> > >> No. *That* would allow all of the following but not the
>>> > example above:
>>> > >>
>>> > >> Geolocation: cid:[e-mail],
>>> > >> Geolocation: cid:[e-mail],cid:[e-mail],
>>> > >> Geolocation: routing-allowed=yes
>>> > >>
>>> > >>>> In addition to that, the text is very explicit that:
>>> > >>>>
>>> > >>>> The routing-allowed
>>> > >>>> parameter MUST be present, even when no locationValue is present.
>>> > >>>>
>>> > >>>> but then it says:
>>> > >>>>
>>> > >>>> If no routing-allowed parameter
>>> > >>>> is present in a SIP request, a SIP intermediary MAY insert this
>>> > >>>> value with a RECOMMENDED value of "no" by default.
>>> > >>>>
>>> > >>>> So its required, but we have rules to follow if its
>>> > missing. But I
>>> > >>>> don't understand how it *can* be required, since the
>>> > sender of the
>>> > >>>> request may not understand/support Geolocation and so
>>> > won't include it.
>>> > >>>
>>> > >>> What we're trying to do here is explicitly give
>>> > instructions to SIP
>>> > >>> intermediary implementers to include the routing-allowed
>>> > parameter if
>>> > >>> one isn't present, with a default value of =no.
>>> > >>
>>> > >> I went back and reread the section containing this text. It is in a
>>> > >> section explicitly about this header. So on reflection I
>>> > suppose the
>>> > >> "MUST be present" was intended to imply "in the
>>> > Geolocation *header".
>>> > >> I took it to mean "in the request".
>>> > >>
>>> > >> Requiring it to be in the header only makes sense if there
>>> > can be at
>>> > >> most one header. And then it only makes sense if the
>>> > syntax is altered
>>> > >> to allow both the routing-parameter and the locationValue
>>> > in the same
>>> > >> header.
>>> > >>
>>> > >>>> ISTM that in reality its only *required* if the is a
>>> > locationValue
>>> > >>>> present, and is otherwise optional.
>>> > >>>
>>> > >>> which is how most would read it if ...
>>> > >>>
>>> > >>>> If no routing-allowed parameter
>>> > >>>> is present in a SIP request, a SIP intermediary MAY insert this
>>> > >>>> value with a RECOMMENDED value of "no" by default.
>>> > >>>
>>> > >>> ... weren't present in the document. But, there is no
>>> > permission to
>>> > >>> allow SIP intermediaries to add the routing-allowed
>>> > parameter, which we
>>> > >>> wanted to cover.
>>> > >>
>>> > >> I'm still confused. Let me state what I think you are after:
>>> > >>
>>> > >> - a request may or may not contain a Geolocation header
>>> > >> - a request may not contain more than one Geolocation header
>>> > >
>>> > > of what you have, this one is one I hadn't considered
>>> > important, but if
>>> > > that gets everything aligned, then I'm all for adding it in.
>>> > >
>>> > >> - a Geolocation header MUST contain a routing-param
>>> > >> - a Geolocation header Must contain zero, one, or two
>>> > locationValues
>>> > >> - you prefer the routing-param to be the last field in the header
>>> > >> - a proxy MAY add a Geolocation header if one is not present
>>> > >> (in which case it MUST include a routing-param)
>>> > >> - a proxy MAY add a locationValue to an existing Geolocation header
>>> > >> if it doesn't already have two locationValues. (And I guess it
>>> > >> could add two if there initially were none.)
>>> > >>
>>> > >> And you would like ABNF that is consistent with the above.
>>> > >
>>> > > with the one caveat, yes.
>>> > >
>>> > >
>>> > >> I'm going to give you some alternatives that should all be
>>> > >> syntactically correct. I'll give you one that meets the above, and
>>> > >> some others that may be more appealing variations. Then we can see
>>> > >> which people prefer.
>>> > >>
>>> > >> 1) The following tries to meet the requirements I spelled
>>> > out above:
>>> > >>
>>> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
>>> > >> Geolocation-value = locationValue [ COMMA locationValue]
>>> > >> COMMA routing-param
>>> > >> / routing-param
>>> > >
>>> > > I hadn't even thought that was possible, but seeing it, I'm amazed I
>>> > > didn't try it
>>> > >
>>> > > (i.e., it's another classic "I could've had a v8" moment)...
>>> > >
>>> > > I'm not as smart as you, Paul <:-|
>>> > >
>>> > >> locationValue = LAQUOT locationURI RAQUOT
>>> > >> *(SEMI geoloc-param)
>>> > >> locationURI = sip-URI / sips-URI / pres-URI
>>> > >> / http-URI / HTTPS-URI
>>> > >> / cid-url ; (from RFC 2392)
>>> > >> / absoluteURI ; (from RFC 3261)
>>> > >> geoloc-param = generic-param; (from RFC 3261)
>>> > >> routing-param = "routing-allowed" EQUAL "yes" / "no"
>>> > >>
>>> > >> This must be accompanied by text stating that there MUST be at most
>>> > >> one Geolocation-header in a request.
>>> > >
>>> > > you've sold me on this one (and yes, I examined all the
>>> > others before
>>> > > jumping on this first one!). Do others have strong opinions
>>> > about why
>>> > > not #1?
>>> > >
>>> > > thank you for this!
>>> > >
>>> > > James
>>> > >
>>> > >
>>> > >> 2) The following is similar to (1), but allows more than two
>>> > >> 'locationValue's
>>> > >>
>>> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
>>> > >> Geolocation-value = *(locationValue COMMA) routing-param
>>> > >> locationValue = LAQUOT locationURI RAQUOT
>>> > >> *(SEMI geoloc-param)
>>> > >> locationURI = sip-URI / sips-URI / pres-URI
>>> > >> / http-URI / HTTPS-URI
>>> > >> / cid-url ; (from RFC 2392)
>>> > >> / absoluteURI ; (from RFC 3261)
>>> > >> geoloc-param = generic-param; (from RFC 3261)
>>> > >> routing-param = "routing-allowed" EQUAL "yes" / "no"
>>> > >>
>>> > >> The same wording is required with it
>>> > >>
>>> > >> 3) The following is a copy from my earlier posting:
>>> > >>
>>> > >> Geolocation-header = "Geolocation" HCOLON Geolocation-value
>>> > >> *( COMMA Geolocation-value)
>>> > >> Geolocation-value = locationValue / routing-param
>>> > >> locationValue = LAQUOT locationURI RAQUOT
>>> > >> *(SEMI geoloc-param)
>>> > >> locationURI = sip-URI / sips-URI / pres-URI
>>> > >> / http-URI / HTTPS-URI
>>> > >> / cid-url ; (from RFC 2392)
>>> > >> / absoluteURI ; (from RFC 3261)
>>> > >> geoloc-param = generic-param; (from RFC 3261)
>>> > >> routing-param = "routing-allowed" EQUAL "yes" / "no"
>>> > >>
>>> > >> The above is overly forgiving, in that it permits zero or more
>>> > >> locationURIs and zero or more routing-params. That then needs to be
>>> > >> tightened up with text. I think the text needs to say,
>>> > more or less:
>>> > >>
>>> > >> - if there are any locationURIs in a sip request,
>>> > >> then a routing-param MUST be present in the request
>>> > >> - there MUST NOT be more than one routing-param present in a
>>> > >> sip request.
>>> > >> - there MUST NOT be more than two locationURIs in a sip request
>>> > >> (if there is really a reason for such a restriction)
>>> > >>
>>> > >> 4) The following is a more radical change:
>>> > >>
>>> > >> Geolocation-header = "Geolocation" HCOLON locationValue
>>> > >> [ COMMA locationValue ]
>>> > >> locationValue = LAQUOT locationURI RAQUOT
>>> > >> *(SEMI geoloc-param)
>>> > >> locationURI = sip-URI / sips-URI / pres-URI
>>> > >> / http-URI / HTTPS-URI
>>> > >> / cid-url ; (from RFC 2392)
>>> > >> / absoluteURI ; (from RFC 3261)
>>> > >> geoloc-param = generic-param; (from RFC 3261)
>>> > >>
>>> > >> Georouting-header = "Geolocation-Routing" HCOLON
>>> > >> ( "yes" / "no" / gen-value )
>>> > >>
>>> > >> This one needs to be accompanied by text stating that each of
>>> > >> Geolocation-header and Georouting-header may appear at most once
>>> > >> in a request, and that if Georouting-header is absent it defaults
>>> > >> to "no".
>>> > >>
>>> > >> 5) A more lenient variant on (4):
>>> > >>
>>> > >> Geolocation-header = "Geolocation" HCOLON locationValue
>>> > >> *( COMMA locationValue )
>>> > >> locationValue = LAQUOT locationURI RAQUOT
>>> > >> *(SEMI geoloc-param)
>>> > >> locationURI = sip-URI / sips-URI / pres-URI
>>> > >> / http-URI / HTTPS-URI
>>> > >> / cid-url ; (from RFC 2392)
>>> > >> / absoluteURI ; (from RFC 3261)
>>> > >> geoloc-param = generic-param; (from RFC 3261)
>>> > >>
>>> > >> Georouting-header = "Geolocation-Routing" HCOLON
>>> > >> ( "yes" / "no" / gen-value )
>>> > >>
>>> > >> This one needs to be accompanied by text stating that
>>> > >> Georouting-header may appear at most once in a request, and that
>>> > >> if Georouting-header is absent it defaults to "no".
>>> > >>
>>> > >> (The Geolocation-header can appear zero or more times.)
>>> > >>
>>> > >> This is only preferred to (4) if more than two locationValues
>>> > >> are acceptable. ISTM that once we allowed two, allowing more
>>> > >> makes sense, with the same limitations imposed with two - that
>>> > >> its up to the recipient to figure out which to use.
>>> > >>
>>> > >> Of the above, I technically and esthetically prefer (5) - or (4) if
>>> > >> the limitation to two URIs is important. I see no reason
>>> > to *require*
>>> > >> the routing-param if the default is understood to be "no".
>>> > >>
>>> > >> Pragmatically I think I prefer (1) - its the least
>>> > variation from what
>>> > >> has been recently discussed that, IMO, makes any sense.
>>> > >>
>>> > >>
>>> > >>>> In that case, an intermediary that adds a locationValue
>>> > not only MAY,
>>> > >>>> but presumably MUST add a missing routing-param if it adds a
>>> > >>>> locationValue.
>>> > >>>
>>> > >>> We can get there (i.e., allow this) without stating this
>>> > is a MUST,
>>> > >>> can't we?
>>> > >>
>>> > >>>> I have never understood why the routing-param is
>>> > required to be last.
>>> > >>>
>>> > >>> maybe it doesn't need to be, but it certainly is easier for
>>> > >>> monitoring/reading human to find if it is last when
>>> > looking at a decode.
>>> > >>>
>>> > >>>> And as my examples show, its difficult/impossible to
>>> > enforce this in
>>> > >>>> ABNF.
>>> > >>>>
>>> > >>>> Thanks,
>>> > >>>> Paul
>>> > >>>
>>> > >
>>> > > _______________________________________________
>>> > > sipcore mailing list
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/sipcore
>>> > >
>>> > _______________________________________________
>>> > sipcore mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/sipcore
>>> >
>>>_______________________________________________
>>>sipcore mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/sipcore
>>
>>_______________________________________________
>>sipcore mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/sipcore
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore