pport of this sort is required on the Session
> Border Controller (SBC). And if yes, then what is the mechanism that is used
> (because there cannot be any fax tone to start off with).
It would seem wise for an SBC to not break a session that is setup
initially with T.38.
--
Kevin P.
uick look through RFC 4566 and RFC
2833 doesn't shed any light on whether 'telephone-event' and
'TELEPHONE-EVENT' should be treated as equivalent or not. However, it
certainly seems that it would be safe for an implementation to treat the
media format in a case-insensitiv
Is there any device/UA who behaves like this?
Yes, I suspect there are many devices that operate like this, if they
support both SRTP and T.38. This would be a very common occurrence if
the user of the device has enabled SRTP.
> Is it practical to update the session of secure RTP with non secu
oes not have a higher CSeq value than the original request,
even for REGISTER and other non-dialog-forming requests. Essentially,
the sequence of requests is treated as a 'dialog' during the 407/retry
cycle. I don't remember this ever causing an interoperability problem.
--
Ke
e of distinguishing the two types of media it could
receive on that port, but of course in practice they never are, and if
they receive G.711 media after they believe they have 'switched' to
T.38, hilarity ensues.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Ja
It doesn't seem like there would be any value in requiring a
UAS to be required to authenticate itself in order to respond to a request.
Do you have an actual problem you are trying to solve here?
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@
pect
responses to have some amount of 'reasonableness', but it should be
prepared for responses to contain completely unexpected contents.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445
ehavior would not be specified by any RFC (and to some extent would not
be RFC compliant, as you'd be changing the semantics of the REGISTER
request).
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: k
isional responses reliably, then you are
not obligated to include an SDP offer in them just because the INVITE
did not contain an offer.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive
e are probably an infinite number of scenarios in which a re-INVITE
could be issued. What do you believe is the value of trying to identify
all possible reasons that you might receive a re-INVITE?
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com
> Is this a valid behavior?
What is your definition of 'valid'?
> Is there any draft or RFC in which this behavior is defined?
No. It's rather widely used, but not specified by any RFC.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium
SDP answer/offer (depending on the presence of SDP offer in the
> INVITE or not)?
Yes, that's exactly where it comes from. The usage of 100rel/PRACK turns
that 181/182 response into a 'reliable response'.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technolog
; If the 100res spec makes this scenario impossible then I don't like it.
Well, this scenario is not very realistic anyway, because as others have
pointed out, "Require: 100rel" in an INVITE is a fairly bad idea to
begin with.
--
Kevin P. Fleming
Digium, Inc. | Director o
ed by UAs that obtained the Contact URI from that registrar will
then include that token, and the receiving UA can 'trust' that the
INVITE was generated by a UA that was authorized by the registrar to do so.
This can easily be sniffed by a third party if the SIP signaling is not
secured
thorized first to REGISTER. Otherwise, it should send 404 Not Found.
True enough; if an SP-SSE that does not support authentication is
exposed to an attacker trying to enumerate AoRs, it will have no choice
but to respond differently for valid and invalid AoRs. Of course, such
an SP-SSE shouldn&#x
whether the AoR in the attempted registration is found in
its database or not.
Olle, do you want to take this to the SIPForum 'techwg' list? If not, I
will.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: k
aces with
> method=SUBSCRIBE, using an address that prefers the server you want to
> transfer to. But the likelihood of that being supported by the
> subscriber is slim to none.
>
> I'm inclined to agree with Dale thatyou just do nothing, and let it
> level out based on attrition
finalized by 2012-01-06. Talks should be submitted by
subscribing to and then posting to the telephony-devroom mailing list
hosted on http://lists.fosdem.org/. If you would like to contact the
devroom organizer directly, please contact Kevin P. Fleming .
Feel free to forward this along to any
On 11/08/2011 02:54 PM, Iñaki Baz Castillo wrote:
> 2011/11/8 Kevin P. Fleming:
>>> So my web browser (that includes the list of Root CA certificates)
>>> inspects both certificates, realizes that the first one is an
>>> intermediate CA certificate, verifies i
usted CA certificates' exists on your system).
I believe this should work just fine for SIP UAs that are using SIP over
TLS; the certificate exchange(s) will occur during the TLS negotiation
and the TLS libraries at both ends will validate them before telling the
application layer that t
e transport of binary message
bodies, but it's certainly allowed. RFC 3261 places no restrictions on
the MIME-types that can appear in the Content-Type header.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@d
or made a proxied call??
> Can I have a sample config(Please not the sample that comes with the source,
> I want a working config file)...
Wouldn't this be more appropriate for a mailing list/forum/etc. operated
by the MjSIP project itself?
--
Kevin P. Fleming
Digium, Inc. | Director of S
On 10/19/2011 03:39 PM, Saúl Ibarra Corretgé wrote:
>
> On Oct 19, 2011, at 8:18 PM, Kevin P. Fleming wrote:
>
>> On 10/19/2011 12:50 PM, Pavesi, Valdemar (NSN - US/Irving) wrote:
>>
>>> The 100-trying will be used to stop the timer T1 (500MSEC) , If any
>>
response (or any other provisional response) stops
Timer B, which defaults to 64 * Timer T1 (so nominally it is 32 seconds).
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsvi
On 10/03/2011 09:32 AM, Iñaki Baz Castillo wrote:
> 2011/10/3 Kevin P. Fleming:
>> I wouldn't require it, no, but I'd offer it as an option. Someone has to
>> get the ball rolling :-)
>>
>> Offering SNI support on the server side is not incompatible with usin
On 10/03/2011 09:24 AM, Iñaki Baz Castillo wrote:
> 2011/10/3 Kevin P. Fleming:
>>> So in this case the SIP client must implement SNI, right? Then until
>>> there is not a draft/RFC stating such requirement for SIP devices, SNI
>>> usage is not possible in SIP.
>&
to the SNI extension after following the normal SIP
name-resolution procedures, but just the default of the name that was
provided in the request URI would be a good start.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpfl
http://tools.ietf.org/html/rfc5922#section-7.1
That's true, it's technically possible for SubjectAltName to be used
this way. However, doing so requires that the cert be re-issued every
time a virtual service is added or removed from the physical server,
which is a burden for the admi
seen a SIP "element" checking the
> SubjectAltName entries in a certificate, most of them just inspect the
> Subject (which requires having a separate certificate for each served
> domain... ever worse... a SIP TLS server listening in a single IP:port
> can only present
to
succeed... whether it will or not is an entirely different question.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.
ndle *usage* of SIP, only the basic
SIP mechanics themselves, without unnecessarily restricting
interoperability with other UAs.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - H
On 08/11/2011 10:13 AM, Iñaki Baz Castillo wrote:
> 2011/8/11 Kevin P. Fleming:
>>> 21.4.18 480 Temporarily Unavailable
>>>
>>> The callee's end system was contacted successfully but the callee is
>>> currently unavailable (for example, is not
r the AoR, then
the "callee's end system" cannot have been "contacted successfully".
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Ja
ct in 1XX
> responses. Maybe we should file an errata.
I've just looked over the errata for RFC3261, and there isn't one
covering this issue. Please do file an erratum for this issue.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digi
: "Outbound Call"> ;party=calling;privacy=off;screen=no*
>
> So my query is with all that can REMOTE-PARTY-ID is can be change in 183&
> 200 OK to same INVITE?
Remote-Party-ID was only described in an Internet-Draft, which has long
since expired. There is no other
on yet), then the server also knows that the
original connection has been lost. There is only one connection to use
to send the response back... the new one that the client opened.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@
Proxy A,
that might be the way to handle this, but until it was posted in this
thread I'd never heard that such a thing was possible.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Da
es not "accept" the 200 response. It receives the 200
> response and *must* then send an ACK. There is no way for it to
> "reject" the response. (This has been discussed in many contexts,
> which I'm too lazy to look up right now.)
I would think that if the
On 06/24/2011 07:18 AM, Brett Tate wrote:
>> Is it valid to interpret that an extension present
>> in 'Require' is also 'Supported' by the UAC?
>
> No; see rfc4028.
That's... bizarre :-)
--
Kevin P. Fleming
Digium, Inc. | Director of Software Tec
27;Require' is used for any extension?
Yes. It would be rather pointless for a UA to indicate that it requires
an extension to be used if it doesn't support that extension.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...
tating that the "domain does not exist".
> In fact, "_" is not a valid symbol for a domain so nobody should
> consider _sip._udp.kamailio.org as a domain.
It *is* a domain. That's why you get a 'no such name' or 'domain does
not exist' respo
m, and the IP-PBX is behind
a NAT and has multiple 'identities' that UAs could see, then it should
be provisioned with multiple certificates and respond with the proper
one based on the source address of the incoming connection (or
destination address of an outgoing connection).
--
Kevin
u are correct, and that 'transport' in this particular
sentence is very specific to the actual transport protocol, and does not
take into account any security layers that may be used on top of it. In
addition, this is going to get more complicated when DTLS-over-UDP is
supported for SIP,
#x27;t that be a SUBSCRIBE setting the subscription expiration to
zero? I wasn't aware that a UAC could send a NOTIFY.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davi
etter response code to return when the user of the
phone has manually rejected/declined the call? '486 Busy Here' seems a
bit inappropriate, although I guess it's not terrible.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: k
PSTN feature that would fork a call. Even the 'call
forward-no answer' and 'call forward-busy' features are implemented by
the target endpoint's switch, not by the calling endpoint's switch.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber:
transaction leg doesn't request.
Is the device you are calling 'proxy' an actual proxy, or a B2BUA? The
expected behavior could differ substantially based on that.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@di
ins multiple streams (one RTP/AVP and
one RTP/SAVP) those are actually *separate* streams, not alternate
offers for the same stream.
As far as I know, the only RFC-compliant way to offer both RTP/AVP and
RTP/SAVP for the same media stream is through SDP capability negotiation.
--
Kevin P.
ple Proxy-Authentication headers
in its 401/407 response, as long as the header differ from each other
(realm, digest method, etc.). This would then allow the UAC to choose
which one it is capable of using and issuing a response to the
appropriate challenge.
--
Kevin P. Fleming
Digium, Inc
ms available. If that means that doing so
would require revising RFC 3261 itself... that seems like a completely
impractical task :-)
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Dav
On 03/22/2011 07:14 AM, Nitin Kapoor wrote:
> Dear All,
>
> i am facing the problem with one of my customer where i noticed that
> Record-Route header containing the "ftag" parameter.
You already asked this question and received an answer.
--
Kevin P. Fleming
Digium, Inc.
hat it was unable to register for that
AoR, but for no apparent reason (since another attempt 60 seconds later
might succeed if one or or more of the existing registrations expired in
that interval).
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@di
nt over
UDP, but the request was received over UDP? Is there an appropriate
response code to send to tell the requester they need to re-issue their
request using a different transport?
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpfle
uestions when they want to; not
because they are obligated to.
It is also possible that very few people on this list are even
knowledgeable about the topic you asked, and so the number of people who
*could* answer the question (if they had time) is small.
--
Kevin P. Fleming
Digium, Inc.
cluded or not and route the call to the same AoR, that's up to you,
but this behavior would not be mandated by the RFCs.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW -
rease the
version number even though the offer has changed... but we can go ahead
and accept it anyway, since it's possible for the session to work as the
user expects in spite of the protocol violation.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...
' line... it's not really used for anything except identifying the
session anyway, there's no value in changing it.
If the PBX in question is the one I think it is, this behavior does not
surprise me :-)
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber:
>
> S_OWNER : o=TLPMSXP2 22660 *22661* IN IP4 69.90.230.210
> S_NAME : s=sip call
> S_CONNECT : c=IN IP4 69.90.230.217
> TIME : t=0 0
>
> Could anyone please let me know if that is okay to increment the session
> version and if any supported document is there?
Was the to-t
ls
required for registering contacts on Dave's AoR there. Since the latter
information is supposed to be kept private between Dave and Dave's
registrar, under normal circumstances that should not be possible.
--
Kevin P. Fleming
Digium, Inc. | Dire
's domain (Biloxi),
> how should bob do?
Bob should register his Contact URI with his registrar, and when he
receives INVITE requests, he should reply to them with a 302 REDIRECT
that sends the call to Dave's AoR.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
unsecured RTP as an option? If so, that
endpoint is allowed to send unsecured RTP as soon as it receives that offer.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kflem...@digium.com
Check us o
X (or potentially even a party
outside the PBX).
It may be possible in this case for Dave's UA to inspect the Request URI
of the incoming request to see if it was directed at his own AoR;
depending on how the call was routed through the proxies, it is possible
that the original Request URI
On 02/17/2011 09:26 AM, Pandurangan R S wrote:
> On Thu, Feb 17, 2011 at 6:40 PM, Kevin P. Fleming
> wrote:
>> It isn't supposed to be; local resolvers should only append their own
>> domain when the name they are asked to resolve does not contain any '.';
&g
pposed to be; local resolvers should only append their own
domain when the name they are asked to resolve does not contain any '.';
if it does, they are supposed to leave it alone.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsvill
the
> others would be good enough to satisfy draft-ietf-sipping-v6-transition, RFC
> 4566, and RFC 1035.
It is indeed number 4; I think the text in the draft is fairly clear on
that point.
Neither 2 or 3 would be 'within the .invalid DNS TLD', and number 1 is
not "a
d to pass through a router
C on their way to him... it does not actually matter to Dave whether the
packets went through C or not, all Dave cares about is that A is the
source of them.
So... rather than proposing a hypothetical situation and asking if SIP
can ensure that it does what you want,
so send
you audio media. Whether you choose to actually play it to your
endpoint, or generate a local ringback indication, is up to you. In the
US, for example, there are a number of mobile carriers who offer the
option of playing 'music' as ringback to callers; if you call one of
(the 200 OK) can be different from answers
that were supplied in provisional responses.
If your SIP implementation is not respecting the SDP answer included in
the 200 OK response, it is not RFC compliant.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive
On 02/09/2011 05:51 AM, Saúl Ibarra Corretgé wrote:
> On Wed, Feb 9, 2011 at 12:39 PM, Kevin P. Fleming
> wrote:
>> The value of punycode is supposed to be that it is transparent to the
>> proxy; it's just a text string that proxy will store, retrieve, compare,
>> an
he DNS resolver
can handle transforming punycode back to the proper bytes to send in the
DNS query, it should "just work" :-)
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - U
ing a
> Join header field."
That seems pretty clearly stated to me; the addition of Replaces or Join
headers is only allowed for a UAC creating a new dialog. There's no need
to explicitly list all the other dialog states in which the headers are
not allowed... because such a list could n
r the SIP client to tell the TLS stack it is using to send
this information to the server during the TLS negotiation.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kflem...@digium.com
Check us o
on requiring more than 32
dynamic payload types in an offer.
I wonder how many implementations would actually correctly process such
an offer... I suspect not many :-)
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - U
On 02/01/2011 08:37 AM, Worley, Dale R (Dale) wrote:
>
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kevin P.
> Fleming [kpflem...@digium.com]
>
> I assume by '
y specifies
the media format (encoding, number of channels, sample rate and media
type), so in your example of an offerer wanting to accept PCMU/16000
they cannot use payload number 0 (zero) for that, because zero is
specified as PCMU/8000/1 and cannot be used for any other media format.
--
Kevi
Authenticate header in
the 401 response. That is the proper way to authorize SIP requests.
>
>
> On Tue, Jan 25, 2011 at 10:13 AM, Kevin P. Fleming <mailto:kpflem...@digium.com>> wrote:
>
> On 01/25/2011 09:08 AM, Wyne Wolf wrote:
> > Hi,
> >
&
4_9080
> From:
> "2426778055"
>> ;tag=8597d1e58953c9c79053d19a5920b528
> Call-ID: 8597d1e58953c9c79053d19a5920b528
> CSeq: 26 BYE
> WWW-Authenticate: Digest realm="SRG",
> nonce="e5bb5b6e08665d981dbd42933bdb0df3", stale=true, algorithm=MD5,
&
you suggest.
> 2. Is this packet repetition is only relevant to the emulated modem
> signals? ( Not for the actual media)
No. You can choose to use it for either or both as your network
requirements dictate.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Dav
On 01/20/2011 04:15 PM, Iñaki Baz Castillo wrote:
> 2011/1/20 Kevin P. Fleming:
>> Unless I'm mistaken, the RFCs also strongly suggest that implementations
>> *not* include the port number in URIs when it is the default,
>
> That's right, but a sentby param is not a
t specified in the Via header,
it is assumed to be the default port, which matches exactly the sent-by
information in the original Via header.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806
u
are right, there's no practical way for the answerer to indicate that it
can only support IPv6 and would prefer an offer that includes IPv6.
To some extent, this 'optimistic' model is good, because it cuts down on
round-trips sending offer/answer pairs until the two end
a good way to indicate that it's possible and a preferred
> way of handling errors.
Indeed, that's a very useful thing to know about :-) Presumably the
488's SDP would indicate "if you had constructed your offer this way, I
would have been able to accept it"?
--
ith BYE (just like for an unacceptable answer) and
> for a missing offer, a dummy answer (with no m-Lines?) is sent in ACK
> followed with BYE.
That seems reasonable to me, although you will likely not see these
situations very often... it's good to be prepared though :-)
--
K
On 01/10/2011 11:08 AM, Olle E. Johansson wrote:
>
> 10 jan 2011 kl. 14.07 skrev Kevin P. Fleming:
>
>> On 01/10/2011 03:59 AM, Olle E. Johansson wrote:
>>> The draft changes the SDP offer/answer model so that an answer has to use
>>> the same protocol family (ipv
he *strongly
recommended* way to offer both IPv4 and IPv6 candidate addresses for a
media stream, if for no other reason than that usage of ICE also
mandates connectivity checks to determine which candidate(s) are
actually suitable for use.
--
Kevin P. Fleming
Digium, Inc. | Director
On 01/08/2011 11:33 AM, Iñaki Baz Castillo wrote:
> 2011/1/8 Kevin P. Fleming:
>> Maybe I'm missing something obvious (it is Saturday morning after all),
>> but why does the UAS need to send an SDP *at all* in order to play
>> announcements? If the UAC included an SDP o
o receive media from the caller, and would just
throw it away if it did), then the media can be sent to the caller
without doing anything more than sending a single '183 Session
Progress', and it does not even need to include an SDP answer.
--
Kevin P. Fleming
Digium, Inc. | Directo
y useful,
because the UAs could have just chosen that connectivity to begin with.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kflem...@digium.com
Check us out at www.digium.com & w
be problematic if you drop received To/From ports when
>>> sending requests within dialog.
>>
>> IMHO it's much better just to ignore port in From/To URI when comparing
>> URI's.
>>
> ___________
> Sip-implemento
response so the client gets a usable address. I
> tried pushing an address into the request before calling
> createResponse(), but that had no effect.
Sounds like you need to find a newer version of your stack, or dive into
it and fix it yourself.
--
Kevin P. Fleming
Digium, Inc. | Direc
IPv6 addresses, and I don't know
> how to work around this. I don't know how to get the server to send an IPv4
> address (leaving aside the question of whether that would be a good thing),
> and apparently Sipper can't use the IPv6 address the server sends. Any he
On 12/09/2010 02:16 PM, Iñaki Baz Castillo wrote:
> 2010/12/9 Kevin P. Fleming:
>>> Sorry, what I want is to allow such invalid bytes as part of the
>>> Display-Name value in From/Contact header.
>>>
>>> display-name = quoted-string / ( token
ot;\\" (%x00-09 / %x0B-0C / %x0E-7F)
I don't see how... the encoding would have to be specified, otherwise
you can't determine what it is.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | ja
93 matches
Mail list logo
