2012/7/27 Worley, Dale R (Dale) :
> On Fri, 2012-07-27 at 10:09 -0400, Roman Shpount wrote:
>> The more I think about it, [...] The continuation of this discussion
>> should probably take in sipcore.
>
> Why don't you write an Internet-Draft containing your proposed
> improvements, and then submit
On Fri, 2012-07-27 at 10:09 -0400, Roman Shpount wrote:
> The more I think about it, [...] The continuation of this discussion
> should probably take in sipcore.
Why don't you write an Internet-Draft containing your proposed
improvements, and then submit it for discussion in Sipcore?
Dale
_
Inaki,
You have misunderstood what I have said: The flow token is generated and
added to the route header by the edge proxy. The flow token that edge proxy
should put in the route header should be constructed in such a way that can
be used to locate the registration from this particular user agent
Hi Roman, sorry for the late response:
2012/6/18 Roman Shpount :
> You can work around the issue you mention by putting the public GRUU in the
> route header instead of flow token. For all the subsequent requests proxy
> will look up if the flow exists for this GRUU and send the request over this
Iñaki,
You can work around the issue you mention by putting the public GRUU in the
route header instead of flow token. For all the subsequent requests proxy
will look up if the flow exists for this GRUU and send the request over
this flow.
Overall I do agree with you that SIP Outbound is fairly r
2012/6/15 Roman Shpount :
> SIP Outbound is all about SIP clients operating from behind NAT, but it
> fails to address sending responses to SIP messages received over TCP.
Hi Roman, as I told in my initial(s) mails in this thread, that's not
the only problem. The worst problem, IMHO, is the fact t
On Fri, Jun 15, 2012 at 10:18 AM, Worley, Dale R (Dale)
wrote:
> Strictly speaking, if the original connection is closed, RFC 3261 says
> that the response should be sent by resolving the host:port in the
> sent-by value using RFC 3263. This would be useful in
> high-availability situations (wher
On Fri, Jun 15, 2012 at 4:50 AM, Iñaki Baz Castillo wrote:
> 2012/6/15 Roman Shpount :
> However I do a "trick". If my proxy receives a request retransmission
> from a different IP:port, it updates its server transaction
> information so responses are now sent to the new IP:port of the UAC.
>
> S
> From: Roman Shpount [ro...@telurix.com]
>
> On the related note, has anybody figured out how the response is supposed
> to be sent to a SIP message if the original TCP connection disconnects?
> Should we be putting some sort of flow tokens in the VIA header? The
> current specification says that
2012/6/15 José Luis Millán :
> RFC 5627 states (at least that is what I understand) that for
> mid-dialog requests in the authoritative proxy, the Path headers in
> the contact binding must be discarded:
>
> 6.1
> +++
> Special considerations apply to the processing of any Path headers
> stored i
2012/6/15 Roman Shpount :
> On the related note, has anybody figured out how the response is supposed to
> be sent to a SIP message if the original TCP connection disconnects? Should
> we be putting some sort of flow tokens in the VIA header? The current
> specification says that response should be
Hi,
RFC 5627 states (at least that is what I understand) that for
mid-dialog requests in the authoritative proxy, the Path headers in
the contact binding must be discarded:
6.1
+++
Special considerations apply to the processing of any Path headers
stored in the registration (see RFC 3327 [3]).
header if original connection is closed, but this is almost
universally useless for clients not located on a public IP.
_
Roman Shpount
From: I?aki Baz Castillo
> Subject: Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive
> in-dialog requests after TCP disconn
2012/6/15 Iñaki Baz Castillo :
> The issue I exposed in my mail occurs because the proxy/registrar in
> which I'm testing GRUU does not replace the RURI of the in-dialog
> request when it contains a GRUU, so it's a bug in the proxy/registrar
> (K.).
Sorry, I didn't read the corresponding t
2012/6/14 Olle E. Johansson :
> I think this is mentioned:
> Section 5.3.2
>
> Implementation note: Specific procedures at the edge proxy to
> ensure that mid-dialog requests are routed over an existing flow
> are not part of this specification. However, an approach such as
> havin
14 jun 2012 kl. 17:51 skrev Iñaki Baz Castillo:
> Hi, please correct me if I'm wrong but Outbound/GRUU has a design
> "issue" when the TCP connection is closed (i.e. SIP outbound proxy
> disconnection). Scenario:
>
>
> alice -- OB-1 -- PROXY/REGISTRAR -- OB-2 -- bob
>
>
> - Bo
2012/6/14 Iñaki Baz Castillo :
> *** ISSUE: ***
>
> - If alice sends an in-dialog request to bob (i.e. re-INVITE) OB-1
> won't change the INVITE route set (of course) so the Outbound
> identifier of alice's connection will still identifying the
> *PREVIOUS* alice's connection.
>
> - So later bob se
Hi, please correct me if I'm wrong but Outbound/GRUU has a design
"issue" when the TCP connection is closed (i.e. SIP outbound proxy
disconnection). Scenario:
alice -- OB-1 -- PROXY/REGISTRAR -- OB-2 -- bob
- Both alice and bob are SIP TCP clients (Outbound/GRUU capable)
connect
18 matches
Mail list logo
