Re: [Sip-implementors] Question about BGCF.

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 has to route ca

Re: [Sip-implementors] Reminder: Regarding SIP Outbound feature implementation

On Thu, Sep 13, 2012 at 12:33 PM, manju nath wrote: > Hi, > > The behavior you have mentioned does not include Outbound feature into > consideration. As per the Outbound feature, a UA can REGISTER to multiple > P-CSCFs, and for the same the server should also support Outbound. > Therefore, in thi

Re: [Sip-implementors] Reminder: Regarding SIP Outbound feature implementation

On Thu, Sep 13, 2012 at 9:43 AM, manju nath wrote: > Hi, > > The aim is not to find the correct P-CSCF by sending Register requests. Its > regarding the implementation of SIP *Outbound feature* i.e. Registration on > multiple P-CSCF's. Now, the question is whether all (say 4 P-CSCF's) the > REGIS

Re: [Sip-implementors] Inputs required on Memory leak in RADV code

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

[Sip-implementors] Behavior for ACK on local transport errors

Given the case where local transport is unable to send a request due to the failure in establishing the connection to the next hop, the condition must be treated as 503 (Service Unavailable) status code. But there is a requirement that transaction layer must submit an ACK for this response as state

Re: [Sip-implementors] Unknown transport in Via Header

See inline.. On Wed, Aug 1, 2012 at 8:00 AM, Keerthi Srinivasan < keerthivarmansriniva...@gmail.com> wrote: > All, > > Can anyone help in unknown transport in Via Header > > 1. If the Proxy / Registrar received the below message. > > OPTIONS sip:u...@example.com SIP/2.0 > To: sip:u...

Re: [Sip-implementors] Duplicate diversion headers in Invite

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

Re: [Sip-implementors] CSeq in Registration process with 407

Hi Manoj, On Sun, Jun 3, 2012 at 3:14 AM, Manoj Priyankara wrote: > Good day Folks, > > I have a doubt in the use of CSeq in the registration process that involve > 407. Call flow is as follows > > UAC >UAS/Proxy > |---F1 (REGISTER)-

Re: [Sip-implementors] problem with SDP part of SIP request

On Thu, Mar 22, 2012 at 7:11 AM, manju nath wrote: > Hi > >i have the following questions regarding SDP of SIP request: > >1) Is there any maximum length defined for each header > present(origin-o, Connection-c & other headers) & sub fields(session id in > origin and sdp protocol version

Re: [Sip-implementors] Server overload issue

On Wed, Mar 21, 2012 at 7:51 AM, Vineet Menon wrote: > Thanks everyone... > I was thinking of a network load balancer..with DNS query... > response code 3xx seems to be a nicer optionbut as they say..sending a > 3xx also needs resources.everything comes to a standstill after > a particular

Re: [Sip-implementors] Server overload issue

Hi Vineet, On Mon, Mar 19, 2012 at 11:10 PM, Vineet Menon wrote: > Hi, > > Does SIP spec. how to overcome overloads? > I have read a couple of papers in which the authors come up > with solutions...but is there nothing in the spec apart from the naive 503 > response code? > Your issue here is s

Re: [Sip-implementors] Duplication of SIP Header

On Tue, Dec 6, 2011 at 3:35 PM, Paul Kyzivat wrote: > The examples below look like some sort of conformance test, rather than > cases that would actually be encountered in practice. If so, I suppose > either you are implementing the tester and looking for what response to > expect, or else you ha

Re: [Sip-implementors] Duplication of SIP Header

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

Re: [Sip-implementors] List of protocols described by SDP

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

[Sip-implementors] List of protocols described by SDP

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 http

Re: [Sip-implementors] Can REFER take place during reINVITE?

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

Re: [Sip-implementors] Can REFER take place during reINVITE?

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

Re: [Sip-implementors] Is it valid/legal to IPv4 control channel and IPv6 data channel?

ed out on my mobile, so apologies for > brevity, errors, and general sloppiness. > > Alex Balashov - Principal > Evariste Systems LLC > 260 Peachtree Street NW > Suite 2200 > Atlanta, GA 30303 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ >

Re: [Sip-implementors] Can REFER take place during reINVITE?

Hi Adam, On Tue, Nov 22, 2011 at 3:40 AM, Adam Frankel (afrankel) wrote: > Hi All, > > I am seeing a scenario for an established call in which an outbound > reINVITE is being done, the far end is sending a TRYING and then a REFER > immediately. We are rejecting this REFER with a 400 Bad Reques

Re: [Sip-implementors] Is it valid/legal to IPv4 control channel and IPv6 data channel?

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 5:06 P

Re: [Sip-implementors] REFER w/Replaces received right after slow start INVITE

Hi Aleksey, The behavior you are describing apears to be wrong to me. From the RFC3515, Section 2: -- Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. -- As one cant send BYE without having an established dialog

Re: [Sip-implementors] Proxy-Require values

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

Re: [Sip-implementors] Consecutive INVITEs (calls) to the same destination (URI)

On Fri, Sep 2, 2011 at 7:53 PM, Iñaki Baz Castillo wrote: > 2011/9/2 Brett Tate : > > Radio station offers free concert tickets to the 10th caller. > > > > Alice makes 10 simultaneous call attempts to radio station to try winning > the tickets! :) > > The radio station *server*/*pbx* should not a

[Sip-implementors] Consecutive INVITEs (calls) to the same destination (URI)

Hi all, I am thinking of a use case, this is below. Alice places a call(INVITE) to Bob, where Bob has multiple devices registered to his URI. INVITE is forked, and all the Bob's devices ring. Bob answers the call on one device. What I am thinking is, would you imagine Alice placing another call

Re: [Sip-implementors] Session -Timer: refresher parameter missing in incoming request

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

Re: [Sip-implementors] Session -Timer: refresher parameter missing in incoming request

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 remove any > call fai

Re: [Sip-implementors] Session -Timer: refresher parameter missing in incoming request

On Monday, July 18, 2011, Krishna Moorthy wrote: > Hi all, > >  What if in the incoming request, the UAC does not add the "refresher" > parameter ( request has Min-SE and Session -expires) ? How should the UAS > behave at this point for session refresh ? > > > 1)      In such a case, would it b

Re: [Sip-implementors] More about SIPS: SIP schema over TLS

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

Re: [Sip-implementors] More about SIPS: SIP schema over TLS

On Tue, Jul 12, 2011 at 10:06 AM, Iñaki Baz Castillo wrote: > 2011/7/11 Iñaki Baz Castillo : > > But, if the UA (caller) uses a SIP URI in the Contact URI of the > > INVITE, in-dialog requests from the callee would nor arrive to the > > caller via TLS. This is: > > > > INVITE sip:b...@domain.com

Re: [Sip-implementors] Subsequent NOTIFY's within a dialog

On Mon, Jul 11, 2011 at 11:14 AM, Shweta Kavishwar < shweta.kavish...@gmail.com> wrote: > Hi, > Is it OK to send a subsequent NOTIFY in a SUBSCRIBE initiated dialog, > before > receiving a successful response > for the earlier NOTIFY request? Does the specification mention otherwise? > I underst

Re: [Sip-implementors] TLS issues proxy-proxy

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. > >>>

Re: [Sip-implementors] TLS issues proxy-proxy

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

Re: [Sip-implementors] TLS issues proxy-proxy

On Thu, Jul 7, 2011 at 3:56 PM, Olle E. Johansson wrote: > > Why would Proxy B want to _validate_ the certificate of Proxy A if it > have not done so when Proxy A established a connection? Proxy B might want > to _verify_ that Proxy A presented the same certificate when Proxy B falls > back. > Pr

Re: [Sip-implementors] TLS issues proxy-proxy

On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson wrote: > > > 2) not perform validation of the upstream element cert. Because by > > > forwarding a response, by definition, it acts as a server in this > particular > > > transaction(request, and any responses to it). > > > > > > Why one would ca

Re: [Sip-implementors] TLS issues proxy-proxy

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

Re: [Sip-implementors] TLS issues proxy-proxy

On Thu, Jul 7, 2011 at 9:34 AM, Iñaki Baz Castillo wrote: > 2011/7/6 Olle E. Johansson : > >> Yes, always. Responses for request arrived via TCP/TLS/SCTP must reuse > >> the same connection if available. > > > But SIP outbound says that this only applies when we have mutual TLS > identification -

Re: [Sip-implementors] TLS issues proxy-proxy

. 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

Re: [Sip-implementors] TLS issues proxy-proxy

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

Re: [Sip-implementors] TLS issues proxy-proxy

Okay, this all gets a little bit complicated and rather interesting. The following is purely my own reasoning. We should not forget that we are talking a TLS layer context here, _not_ TCP. That is, the underlying TCP connection should not require a continuous _established_ state. But rather the TC

Re: [Sip-implementors] TLS issues proxy-proxy

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

Re: [Sip-implementors] TLS issues proxy-proxy

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

Re: [Sip-implementors] TLS issues proxy-proxy

Hi Olle, please see below.. On Wed, Jul 6, 2011 at 3:15 PM, Olle E. Johansson wrote: > > 6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo: > > > 2011/7/6 Olle E. Johansson : > >> Now, consider that a UA has configured a proxy as an outbound proxy. The > connection between them is out of scope for n

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

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

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

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

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

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 >>

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

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

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

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

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

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

Re: [Sip-implementors] INVITE over TLS without "sips". Which URI must add the proxy in Record-Route?

Hi Inaki, On Tue, Jul 5, 2011 at 10:43 AM, Iñaki Baz Castillo wrote: > Hi, I'm experimenting a problem with a client (PJSIP) connecting to a > proxy via TLS: > > - The client uses "sip:" scheme in INVITE headers and "sip:" with > ";transport=tls" in Contact header. It is valid according to some

Re: [Sip-implementors] NAPTR lookup library, API

On Thu, Jun 30, 2011 at 4:55 PM, Iñaki Baz Castillo wrote: > 2011/6/30 Saúl Ibarra Corretgé : > > Did you check c-ares (http://c-ares.haxx.se/)? I haven't used it myself > but I've seen it in some networking related projects. Just curious. > > As the website of udns says: > > c-ares (as of versio

Re: [Sip-implementors] NAPTR lookup library, API

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

[Sip-implementors] NAPTR lookup library, API

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 li

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

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

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

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

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

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

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

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

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

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 ;transport=tcp but "sips" with ;transport=tls. Is "tls" a real > > transport or not? why "sips" and ;transport=

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

On Fri, Jun 17, 2011 at 1:07 PM, Aaron Clauson wrote: > On Wed, Jun 15, 2011 at 8:52 PM, Iñaki Baz Castillo wrote: > > > Hi, according to RFC 3261 a SIP URI should not contain ;transport=tls > > as "tls" is not a valid transport (it should be "tcp" in case of TLS > > over SCTP, or "sctp" in case

Re: [Sip-implementors] SIP URI scheme "sip" and ; transport=tls, what to do in a proxy?

On Wed, Jun 15, 2011 at 8:52 PM, Iñaki Baz Castillo wrote: > Hi, according to RFC 3261 a SIP URI should not contain ;transport=tls > as "tls" is not a valid transport (it should be "tcp" in case of TLS > over SCTP, or "sctp" in case of TLS over SCTP and so). > > So the correct way is using a "sip

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

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

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

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

Re: [Sip-implementors] RFC 3261: "The default is 5061 for sip: using TLS over TCP and sips: over TCP" (what ??)

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

Re: [Sip-implementors] RFC 3261: "The default is 5061 for sip: using TLS over TCP and sips: over TCP" (what ??)

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

Re: [Sip-implementors] RFC 3261: "The default is 5061 for sip: using TLS over TCP and sips: over TCP" (what ??)

On Fri, Jun 3, 2011 at 11:26 PM, Iñaki Baz Castillo wrote: > 2011/6/3 Iñaki Baz Castillo : > > Please let me know if I'm correct or wrong in points [1], [2] and [3]. > > IMHO it would be much easier if ;transport=tls would be allowed but > > it's deprecated by RFC 3261 and 5630, so we get a confu

Re: [Sip-implementors] Proxy matching Route URI

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

Re: [Sip-implementors] Proxy matching Route URI

On Tue, May 31, 2011 at 8:32 AM, Harbhanu wrote: > >The proxy should remove (after the necessary processing) all topmost > >routes that are recognized as its own (on the 16.4 step of rfc3261), > >otherwise on the next step (16.5 of rfc3261) it would have to forward > >the request to itself. > > I

Re: [Sip-implementors] Stateful proxy and CANCEL for a non matching transaction => 481?

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

Re: [Sip-implementors] Stateful proxy and CANCEL for a non matching transaction => 481?

Hi all, 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 the changes introduced in rfc6026 are applied: 16.7 Response Processing When a response is received by an

Re: [Sip-implementors] Proxy receives 200 for INVITE while in "completed" state

On Tue, May 10, 2011 at 1:16 PM, Iñaki Baz Castillo wrote: > 2011/5/10 Iñaki Baz Castillo : > > Later legA replies 480 so the proxy client transaction transitions to > > "completed" state and remains there for a while (a timer and so). > > > > A few seconds later, leg B (which has not received or

Re: [Sip-implementors] Proxy receives 200 for INVITE while in "completed" state

On Tue, May 10, 2011 at 12:33 PM, Iñaki Baz Castillo wrote: > Hi, a proxy does parallel forking for an INVITE to leg A and B. > > Later legA replies 480 so the proxy client transaction transitions to > "completed" state and remains there for a while (a timer and so). > > Hi Inaki, shouldn't when

Re: [Sip-implementors] Reg. SIP version string

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, Brez On

Re: [Sip-implementors] Client and Server using the same IP Address

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

Re: [Sip-implementors] Client and Server using the same IP Address

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

Re: [Sip-implementors] lack of SDP items

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

Re: [Sip-implementors] lack of SDP items

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

Re: [Sip-implementors] Stateful proxy and CANCEL for a non matchingtransaction => 481?

> > 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

Re: [Sip-implementors] How to avoid hard coding of IP Address?

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 avoid the

Re: [Sip-implementors] RTP header followed by the RTP header extension

following the CSRC list if present." > > So, CSRC list first, then extension header :-). > > Best regards, > > Peter > > On Sat, Apr 2, 2011 at 4:05 PM, Brez Borland wrote: > > > Hello folks, > > > > Apologies if this should not go onto this list, please

[Sip-implementors] RTP header followed by the RTP header extension

Hello folks, Apologies if this should not go onto this list, please suggest where else should I look for advice in this case. Below is the snip from the rfc3550, which is a bit confusing. Fields X and CC specify that, if set, they MUST follow the RTP header. My question is, if both X and CC are

Re: [Sip-implementors] User part in SIP URI

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] > > >

[Sip-implementors] User part in SIP URI

Hello all, I have doubts regarding the user part in SIP URIs. The following is quoted from rfc3261: = 19.1.3 Example SIP and SIPS URIs sip:al...@atlanta.com sip:alice:secretw...@atlanta.com;transport=tcp sips:al...@atlanta.com?subject=project%20x&priority=ur

Re: [Sip-implementors] Query on qvalue in SIP headers

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 > > preference    =    "q" EQUAL >

Re: [Sip-implementors] REGISTER request, connection termination

: > Inline. > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On >> Behalf Of Brez Borland >> Sent: woensdag 9 december 2009 0:43 >> To: Dale Worley >> Cc: sip-implemento

Re: [Sip-implementors] REGISTER request, connection termination

Dale has a point. I was impressed watching talk dedicated to ipv6 where major minds behind ipv6 development seemed to be straight ignorant, or least interested, in the notion of private network implementations such as NAT. their position is that every device should have a public IP. Which in my opi

Re: [Sip-implementors] Clarification of Redirect originator

recursion, the proxy is still acting as a proxy; it is just forking > the request to more locations. > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brez Borland

[Sip-implementors] Clarification of Redirect originator

Hi all, If I have UAC who is sending a REGISTER request trough proxy server. Proxy server sends this request further on to REGISTER server. REGISTER server sends a Redirect response to the proxy server. Now, should proxy server send this Redirect response to UAC, or should it try to send the REGI

Re: [Sip-implementors] REGISTER request, connection termination

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

Re: [Sip-implementors] REGISTER request, connection termination

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: >> >>

[Sip-implementors] REGISTER request, connection termination

Hi all, Below I assume using tcp transport for registrations. As I understand, while using a reliable transport for dialogs the connection between UAC and the next hop is active until the dialog is terminated by one party sending BYE and another party responding back. The connections on both side