Hi Brett,
Thanks for your quick response, RFC6026 was the answer to my concerns.
Regards,
Brez
On 03/04/15 12:11, Brett Tate wrote:
Hi,
Since the question is currently vague, you might want to ask again (and
maybe reference the section of RFC 3261 or RFC 6026 that you are
attempting to
Hi all,
As I understand ACK request is picked up by the transport layer and
passed directly to the UAS, at which stage UAS performs ACK request
matching to any completed transactions (i.e. the one it has acknowledged
with 2xx). Is my understanding correct?
Thanks,
Brez
Hi Paul,
Please see inline..
On 2/28/2015 10:58 PM, Paul Kyzivat wrote:
On 2/28/15 3:36 PM, brez wrote:
Hello,
Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates resources (ports) for a non-existent
Hello,
Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates resources (ports) for a non-existent media session?
Thanks,
Brez
___
Sip-implementors mailing
if RE-REGISTER fails at endpoint due to timeout
or some other reason say (authorization removed)?
I think the question is very generic, have you looked at the RFC3261?
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors
dtmf-relay
Content-Length: 26
Signal= 6
Duration= 100
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
nds on the type of content used
(Content-Type header). Each content type has it's own syntax defined.
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Hi Henry,
I believe you will find it all in: TS 23.228, Section 4.6.4 Breakout
Gateway Control Function.
Regards,
Brez
On Mon, Mar 25, 2013 at 9:06 AM, Harry S wrote:
> Hi
>
> This question is related to BGCF in IMS networks. I am confused with
> scenarios where IMS network
ies and how UAC should perform
registrations. I understand that UAC can initiate parallel "flows" or can
choose to do this sequentially (i.e. for the reason to save battery etc.).
Regards,
Brez
___
Sip-implementors mailing list
Sip-
r the previous one or
the previous REGISTER request has timed out.
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Hi Rakesh,
This is SIP specifications related mailing list. Your problem is specific
product related, therefore you should refer to Radvision team with this.
On Mon, Sep 10, 2012 at 2:56 PM, Rakesh Rajkumar wrote:
> >
> > Hi All,
> >
> > Observed memory leak (of about 32-48 bytes) for ever
mission.
So in the case where local transport has failed, there is no point in
submitting an ACK request to the local transport as the 503 response was
received due to the failing local transport. How would you suggest to
approach this situation? Would this be something implementatio
--
When the UAC creates a request, it MUST insert a Via into that
request. The protocol name and protocol version in the header field
MUST be SIP and 2.0, respectively.
So the request you
Hi Vivek, inline
On Fri, Jul 13, 2012 at 7:52 PM, Vivek Singla wrote:
> Thanks Brett for the corrected number. So I was looking into this rfc, I
> didn't see any error conditions mentioning a duplicate diversion header.
> I am forgetting, but SIP has its own way of stopping the loops and looping
r. For full answer to your question refer
to RFC3261, Section 8.1.3.5 Processing 4xx Responses, last paragraph on the
Page 45.
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
re the document/rfc name so that i can refer... :)
>
>
IMHO if optional header is present and it doesn't conform to the
specification one should respond with 606 and include the Warning header
field describing the reason.
Brez
___
Sip-implementors ma
e above the usual daily traffic, or you
might want to have a deployment that can accomodate four times above the
usual. It is up to you what you want to account for, and how you build your
infrastructure. Get your numbers first then you will be able to tell how
your infrastructure should look l
Your issue here is scalability. SIP addresses this with 3xx (redirect)
responses. You must design your servers with this in mind. What you want is
to never send a 503 response, but rather issue a 3xx response to redirect
to another server.
Brez
>
>
e concern of
the downstream elements, and I wouldn't allow pass this junk through
because, as Paul mentioned there, depending on the implementation the
receiver might, or might not, process the request. And sending request
downstream with the uncertainty of i
interesting, anybody to comment on this?
On Wed, Nov 30, 2011 at 1:46 PM, Keerthi Srinivasan <
keerthivarmansriniva...@gmail.com> wrote:
> Hi All,
>
> If the SIP stack receives the duplication Mandatory SIP Header then the SIP
> will send failure response or successful response.
>
> Ex:
> Scenari
s MSRP
and RTP you are aware of are making use of SDP?
Thank you,
Regards,
Brez
> Thanks and Regards,
> Vivek Talwar
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Br
Hi all,
I wonder is there a list of protocols that make use of SDP? I know RTP, and
MSRP are described in SDP. But what are other protocols that make use of it?
Thanks,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
On Tue, Nov 22, 2011 at 11:27 PM, Brez Borland wrote:
> Hi Mark,
>
> I think that INVITE has to be answered. This is what "RFC3261, Section
> 14.1 UAC Behavior" says:
>
>Note that a UAC MUST NOT initiate a new INVITE transaction within a
>dialog while a
n Adam's case his INVITE transaction is pending,
and he cannot act upon the REFER (by initializing another INVITE) while he
is waiting for that INVITE to finish.
Thoughts?
Regards,
Brez
On Tue, Nov 22, 2011 at 8:45 PM, Mark Michelson wrote:
> On 11/22/2011 03:42 AM, Brez Borla
Hi Alex,
But that's what I said, these are two separate channels and can be done
over IPv4 and IPv6.
Regards,
Brez
On Tue, Nov 22, 2011 at 9:47 AM, Alex Balashov wrote:
> Curious, why not? In principle, if the endpoints support IPv6 for media,
> why can't that be describe
way
> whether this is allowed. Can anyone comment?
>
>
You are right to reject it. Caller can send REFER on it's early dialogs,
calle can send REFER only on confirmed ones. This question appeared
recently, search for "REFER w/Replaces received right after slow start
INVITE&q
Hi Michael,
SIP is signalling, and SDP describes the media session. These are two
separate channels. I can't see SIP being done through IPv4 and media
session over IPv6 to be a problem. This is theory. But can anybody comment
from their experience?
Regards,
Brez
On Mon, Nov 21, 2011 at
in place, this
makes me think that REFER can be sent only after ACK was received.
Otherwise, wouldnt it be enough just to "redirect" the caller?
Can anybody else comment on this?
Thanks,
Brez
On Tuesday, October 25, 2011, Aleksey Entsov wrote:
> Hello Experts,
>
> I
Have a look at http://www.iana.org/assignments/sip-parameters it contains
the whole list of current option tags. Look under the "Registry Name: Option
Tags".
Regards,
On Sun, Sep 18, 2011 at 1:52 PM, Iñaki Baz Castillo wrote:
> Hi, where could I get the list of exisiting values for Proxy-Requir
tion *server*/*pbx* should not accept two calls from
> Alice then. It's just a local policy.
>
Great. So in short it's a local policy. That's what I was thinking of
myself. Thanks all for your input!
Brez
___
Sip-implementors mailin
his?
Thank you for your input,
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
sorry, I meant:
...UAS can choose to be a _refresher_ ...
Cheers.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
On Mon, Jul 18, 2011 at 7:27 PM, Krishna Moorthy wrote:
> Hi Brez,
>
> I know, what I am basically trying to work out is an optimal
> implementation for the gateway, when the gateway is the UAS, I want to put
> the onus on the UAS to be the refresher, this in my opinion will re
. Thanks.
Hi Krishna, have a look at rfc4028, Section 9, Table 2. The paragraph
under says that if UAC did not provide the refresher parameter the UAS
can decide what to put into the response (uac/uas)..
Regards,
Brez
___
Sip-implementors maili
On Wed, Jul 13, 2011 at 11:27 AM, Iñaki Baz Castillo wrote:
> 2011/7/13 Brez Borland :
> > Interesting thing, rfc3261, Section 8.1.1.8 says:
> >
> >If the Request-URI or top Route header field value contains a SIPS
> >URI, the Contact header field MUST
nd SIPS into Contact
when sending a request, but you should as well add a top Route header(the
outbound proxy) having a SIPS schema.
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
efinitive answer,..
Regards,
Brez
>
> Thanks,
> Shweta.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
___
On Thu, Jul 7, 2011 at 7:22 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Iñaki Baz Castillo :
> > 2011/7/7 Iñaki Baz Castillo :
> >> 2011/7/7 Brez Borland :
> >>> I think transport/transaction layers should work to prevent cases like
> this.
> >>>
On Thu, Jul 7, 2011 at 6:00 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Kevin P. Fleming :
> > If we're talking about TCP here (as I believe we are, since DTLS isn't
> > part of the discussion yet), then the server also knows that the
> > original connection has been lost. There is only one connecti
e
from the very first email in this thread we are discussing, aren't we.
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
ake sense to verify a certificate
> > when sending a response using the fallback mechanism (sending it to
> > the Via sent-by-host).
> >
> If you still have a valid connection. But if you don't
>
You silently discard the response. This is as per rfc3261, Section 16.9.
This is one helluva topic!
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Brez Borland :
> > I think once TLS context is invalidated(i.e. rejected to be resumed by
> Proxy
> > A), Proxy B should either:
> >
> > 1) return an error to the downstream UAS (i.e. failure to s
certificate of an upstream element when
forwarding a response, if one doesn't case about that validity when he's
forwarding a request?
- Then open a TLS connection with the resolved adrress (proxy A).
>
> - Upon TLS connection, proxy A would show its ce
. How SIP stack should treat TLS rejection, 480, 481, 603..?
Also, I see a third possible case where the upstream Proxy A down and not
reachable. Should TLS layer return a timeout of some kind, what return code
should SIP use in this case?
Regards,
Brez
On Wed, Jul 6, 2011 at 9:54 PM, Brez B
On Wed, Jul 6, 2011 at 9:54 PM, Brez Borland wrote:
> .. by the TCP context could fail,
I meant "TLS context"...
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists
e when TLS connection is broken? Is it
timeout, or something else, cause looking at rfc5246 I can't find anything
related..
Comments please,
Regards,
Brez
On Wed, Jul 6, 2011 at 8:11 PM, Olle E. Johansson wrote:
>
> 6 jul 2011 kl. 18.19 skrev Iñaki Baz Castillo:
>
> > 2011/7/
On Wed, Jul 6, 2011 at 4:54 PM, Olle E. Johansson wrote:
>
> 6 jul 2011 kl. 17.28 skrev Brez Borland:
>
> > On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo
> wrote:
> > 2011/7/6 Olle E. Johansson :
> > >> Good question. However, checking a server certifica
On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo wrote:
> 2011/7/6 Olle E. Johansson :
> >> Good question. However, checking a server certificate (matching the
> >> domain) just makes sense (IMHO) for requests. This is, an UAC sends a
> >> request to a proxy/server (depending Route or RURI). Th
PS:
> uri. It needs to validate the SIPS session and get the server certificate
> for the response... The UA can and should send the response trying to reuse
> the same connection though. THat's why I used two proxys in this example.
>
>
What about rfc5923, SIP Co
On Tue, Jul 5, 2011 at 1:32 PM, Iñaki Baz Castillo wrote:
> 2011/7/5 Brez Borland :
> > I think this is a complete misinterpretation of the nature of
> Record-Route
> > mechanism. As opposed to RURI, Record-Route gives a one-hop behavior, and
> > indicating SIPS s
On Tue, Jul 5, 2011 at 12:58 PM, Iñaki Baz Castillo wrote:
> 2011/7/5 Brez Borland :
> > Have a look at:
> > pjsip/src/pjsua-lib/pjsua_call.c: get_secure_level();
> >
> > It seems to me that PJSIP does not support SIPS scheme in Record-Route.
> That
> > said
On Tue, Jul 5, 2011 at 1:14 PM, Brez Borland wrote:
> On Tue, Jul 5, 2011 at 1:01 PM, Iñaki Baz Castillo wrote:
>
>> 2011/7/5 Iñaki Baz Castillo :
>> > 2011/7/5 Brez Borland :
>> >> A very interesting thing I have just encountered, rfc5603 Section 3.1.4
>>
On Tue, Jul 5, 2011 at 1:01 PM, Iñaki Baz Castillo wrote:
> 2011/7/5 Iñaki Baz Castillo :
> > 2011/7/5 Brez Borland :
> >> A very interesting thing I have just encountered, rfc5603 Section 3.1.4
> >> says:
> >>
> >> The transport=tls parameter ha
isted. Being rather a hack, or a workaround.
On Tue, Jul 5, 2011 at 12:35 PM, Brez Borland wrote:
> Have a look at:
> pjsip/src/pjsua-lib/pjsua_call.c: get_secure_level();
>
> It seems to me that PJSIP does not support SIPS scheme in Record-Route.
> That said, you have to put SI
Have a look at:
pjsip/src/pjsua-lib/pjsua_call.c: get_secure_level();
It seems to me that PJSIP does not support SIPS scheme in Record-Route. That
said, you have to put SIP and "transport=tls" when writing Record-Route.
Regards,
Brez
On Tue, Jul 5, 2011 at 12:16 PM, Brez Borland wr
; in Contact header. It is valid according to some RFC.
>
> - The proxy routes the INVITE via UDP and adds a Record-Route like this:
>
>Record-Route:
>
Did you try without the transport parameter at all, just "sips"?
Regards,
Brez
>
> - However the the clien
ty is
> here, only "wrappers" have to be written.
>
Thank you for input everybody! I am curious, what about Java and C#, do they
have libraries to resolve NAPTR?
Regards,
Brez
>
> --
> Iñaki Baz Castillo
>
>
___
On Thu, Jun 30, 2011 at 3:35 PM, Iñaki Baz Castillo wrote:
> 2011/6/30 Brez Borland :
> > Could anybody suggest libraries I can use to query NAPTR records. I am
> > interested in those available for linux/bsd platforms. GPL/LGPL/BSD
> > licensed.
> >
> > I had b
Hi all,
Could anybody suggest libraries I can use to query NAPTR records. I am
interested in those available for linux/bsd platforms. GPL/LGPL/BSD
licensed.
I had bad luck searching for this on the web.
Thank you,
Brez
___
Sip-implementors mailing
Also, to secure the outgoing connection to the first hop we could use
rfc3329?
Regards
On Sun, Jun 19, 2011 at 6:45 PM, Iñaki Baz Castillo wrote:
> 2011/6/19 Brez Borland :
> > On Sat, Jun 18, 2011 at 3:47 PM, Iñaki Baz Castillo
> wrote:
> >>
> >> I agree. Rfc
proxy will contact the actual user through the secure connection. Am I
talking rfc5626 here?
Regards,
El 17/06/2011 16:01, "Brez Borland" escribió:
>
> On Fri, Jun 17, 2011 at 2:53 PM, Brett Tate wrote:
>
> > For what it is worth... ...
>
> Thanks Brett. After
sip-
> > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brez Borland
> > Sent: Friday, June 17, 2011 9:46 AM
> > To: Aaron Clauson
> > Cc: sip-implementors@lists.cs.columbia.edu
> > Subject: Re: [Sip-implementors] SIP URI scheme "sip" and ;
> > transport=tl
On Fri, Jun 17, 2011 at 2:46 PM, Brez Borland wrote:
> On Fri, Jun 17, 2011 at 1:59 PM, Aaron Clauson wrote:
>
>> From: Iñaki Baz Castillo [mailto:i...@aliax.net]
>> > Good point. But honestly, this becomes ugly and complex. So, "sips"
>> > with ;transpor
ed to be mandatory.
>
> I wonder how you would specify a SIP URI that used TLS over SCTP?
>
I understand this is not possible. If you use SIP you don't use TLS.
Where there is intention to use security _only_ to the next hop, protocol
tunneling/encapsulat
want your connection to be secure
only to the next(first) hop, you configure to use a proxy explicitly.
>From here is the question, should the protocol implement the rule where
security is used only to the next hop? IMHO, it would only complicate it.
Regards,
Brez
> Regards,
> Aaron
s given, so perform
> _sip._tcp.lalala.com SRV query or, if it does not exist, use port
> 5060, and open a TCP connection.
>
> c) Whatever other solution.
>
>
I would say that "sip:al...@lalala.com;transport=tls" should be treated as "
On Fri, Jun 10, 2011 at 1:46 PM, Iñaki Baz Castillo wrote:
> 2011/6/10 Bob Penfield :
> > Except for 100 (Trying), a 1xx should always be forwarded upstream toward
> the UAC. Remember, all transactions complete independently. There may be a
> 2xx final response right behind the 1xx response. The
On Thu, Jun 9, 2011 at 10:32 PM, Iñaki Baz Castillo wrote:
> 2011/5/11 Bob Penfield :
> > You have it correct. The proxy's job is to pass the CANCEL on each branch
> of the matching transaction. The basic rule of SIP is that all transactions
> complete independently. The state of the transactions
On Mon, Jun 6, 2011 at 2:37 PM, Iñaki Baz Castillo wrote:
> 2011/6/6 Brez Borland :
> >> Also, the fact that the Via sent_transport does require to be TLS
> >> rather than TCP, makes the confusion worse. Basically it means that
> >> the concept of "transpo
On Mon, Jun 6, 2011 at 2:12 PM, Iñaki Baz Castillo wrote:
> 2011/6/6 Iñaki Baz Castillo :
> > PS: However there are a lot of devices using ;transport=tls param. I
> > think the confusion is very extended.
>
> Also, the fact that the Via sent_transport does require to be TLS
> rather than TCP, mak
PS:u...@domain.com;transport=tcp<--- good. (with SIPS we imply TCP
transport here, but to add "transport=tcp" can not hurt)
SIPS:u...@domain.com;transport=udp <--- good (though tls/udp is not here
now but one day it will..)
SIPS:u...@domain.com;transport=sctp <--- good.
Reg
On Tue, May 31, 2011 at 11:54 AM, Iñaki Baz Castillo wrote:
> 2011/5/31 Brez Borland :
> > Looking at the issue at hand, Iñaki brings me this concern. What if
> request
> > is injected with the number of Route headers pointing to the local
> > elemen(s)t? How to validate
ointing to the local
elemen(s)t? How to validate that? rfc3261 is talking about loop detection in
regards to the Via headers, not Route.
Regards,
Brez
>
>
> ***
> This e-mail and attachments conta
On Wed, May 25, 2011 at 11:22 AM, Iñaki Baz Castillo wrote:
> 2011/5/25 Brez Borland :
> > To supplement the concern that forwarding of non-matched requests by the
> > stateful proxy is wrong, here is the excerpt from rfc3261 regarding the
> > processing of responses after t
was no clarification
introduced to clarify the behavior with CANCEL.
Regards,
Brez
On Tue, Apr 19, 2011 at 3:48 PM, Worley, Dale R (Dale) wrote:
>
> From: sip-implementors-boun...@lists.cs.columbia.edu [
> sip-implementors-boun...@lists.cs.col
it correctly I think it's much easier than what I expected
> :)
>
>
Hi Inaki, I think what you are looking for is Timer D. Have a look in the
rfc3261, the last paragraph on the page 126, and the page 127.
Regards,
Brez
> Thanks to Vivek and Brez for making m
response is not chosen.
Tells me that you have to wait for all forked destinations to answer?
Regards,
Brez
> A few seconds later, leg B (which has not received or processed the
> CANCEL yet) replies 200. What should do the proxy? forward the
> request? or ignore it? I assume it mus
If we are strict on the interpretation, then any implementation is free to
send upper/lower case. But we can see that the spec. is leaning towards the
version being implemented in the upper case. I'd say, lower-case
implementation are right as well, but are not self-respecting.
Regards,
Bre
On Thu, May 5, 2011 at 3:26 PM, Iñaki Baz Castillo wrote:
> 2011/5/5 Brez Borland :
> > Server code binds, client code should not.
>
> Wrong. A client is a UA, which is UAC + UAS, and UAS must bind to
> listen for incoming requests/responses.
>
> When the client uses SIP
On Wed, Apr 27, 2011 at 11:43 PM, Brandon W. Yuille wrote:
> Just a hunch, but they're both probably trying to bind to port 5060 and
> one of the bind()'s is failing. What's your sin_port for each of those
> and are your checking the result of your bind() call?
>
> Brandon
>
Server code binds, c
Hi Ravi, I will argue. Please see below.
On Wed, Apr 20, 2011 at 1:45 PM, Saúl Ibarra Corretgé wrote:
> Hi,
>
> On Wed, Apr 20, 2011 at 2:01 PM, Brez Borland wrote:
> > If I would ought to build the UAS, I would make it respond with 606 (Not
> > Acceptable), and include War
If I would ought to build the UAS, I would make it respond with 606 (Not
Acceptable), and include Warning header with text description which
parameter is missing. I would include the first missing parameter in the
warning text. Further, when the UAC sends the request with some another
parameter mis
>
> RFC 3261 states:
>
> If a response context is not found, the element does not have any
> knowledge of the request to apply the CANCEL to. It MUST statelessly
> forward the CANCEL request (it may have statelessly forwarded the
> associated request previously).
>
> But this cannot be my
This is a purely coding related question, and has nothing to do with SIP.
You should bring question to the list concerned with the language you are
using for your implementation.
Regards,
Brez
On Mon, Apr 18, 2011 at 8:44 AM, Siga wrote:
> Hi,
> I need some information of how can I avo
Great, this answers. Thank you Peter.
Regards,
Brez
On Sat, Apr 2, 2011 at 7:07 PM, Peter Krebs wrote:
> Hello,
>
> >From RFC 3550, sec. 5.3.1:
>
> "If the X bit in the RTP header is one, a variable-length header extension
> MUST be appended to the RTP header,
clarification of the question
is needed.
Thank you,
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Thanks everybody for your comments.
It is clear to me now I was not counting for different contexts while
working on URIs.
Regards,
Brez
On Wed, Feb 23, 2011 at 5:20 PM, Worley, Dale R (Dale) wrote:
> > From: sip-implementors On Behalf Of Brez Borland [brez...@gmail.com]
> >
>
user part, or the address to be enclosed in
the angle brackets. I would appreciate if anybody would correct, or support,
me in this.
Help is greatly appreciated.
Regards,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.ed
Hi Prashanth,
I think dot is an "optional", and it should be present only if it is
followed by digits.
Regards,
Brez
On Thu, Mar 18, 2010 at 2:58 PM, prashanth.me
wrote:
> Hi,
>
> As per ABNF Grammar of the 'preference' parameter
> ---
u aware of your resources,
taking NAT away enables other parties to be aware of them.
Meantime I do believe that businesses suffer from unavailability of IP
addresses. Hopefully we come to IPv6 sometime soon.
Regards,
Brez
On Wed, Dec 9, 2009 at 8:30 AM, Tom Uijldert wrote
opinion would be great yes. But
NAT is the concept which has many uses as well, and I believe it is
not going to go away very soon. some academics are just weird I guess.
Brez
On Mon, Dec 7, 2009 at 8:43 PM, Dale Worley wrote:
> On Mon, 2009-12-07 at 21:11 +0100, Iñaki Baz Castillo wrote:
&g
Hi Brett,
Thank you for pointing this out,
Regards,
Brez
On Wed, Nov 25, 2009 at 11:28 AM, Brett Tate wrote:
> See 3xx discussions within rfc3261 section 16.7. The 3xx can be proxied or
> the proxy can recurse on the targets from the 3xx's Contact entries. When
> doing the
, redirection allows for considerable network
scalability.
My question is, can the proxy be considered as a request originator?
Or is it strictly UAC.
I am trying to solve this puzzle and fail to do it myself, please
gurus of sip, I will greatly appreciate your help,
Thank you,
Regards,
Brez
That is a shame indeed.. :(
On Tue, Nov 17, 2009 at 11:15 PM, Iñaki Baz Castillo wrote:
> El Miércoles, 18 de Noviembre de 2009, Brez Borland escribió:
>> Thank you all, it is clear to me now.
>>
>> Quick look at 5626. The new spec is big.
>
> Too big, too complex a
Thank you all, it is clear to me now.
Quick look at 5626. The new spec is big. But though made it easier on
me. At least we came up with the way to tackle these situations.
Regards,
Brez
On Tue, Nov 17, 2009 at 10:38 PM, Paul Kyzivat wrote:
>
>
> Brez Borland wrote:
>>
>>
dialog is wrong. That the
dialog enforces the connections to stay open. Where REGISTER, is a set
of transactions that do not require connection to stay active.
Thank you,
Brez
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
96 matches
Mail list logo
