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
> 
> 
> - Both alice and bob are SIP TCP clients (Outbound/GRUU capable)
> connected to OB-1 (Outbound-Proxy-1) and OB-2 respectively.
> 
> - Both alice and bob are registered in PROXY/REGISTRAR through their
> outbound proxies using Path.
> 
> - alice calls bob through OB-1 which routes the INVITE to the PROXY
> which obtains the location of bob and routes the INVITE to OB-2. OB-2
> routes it to bob based on the Outbound identifier in the Route added
> by the PROXY/REGISTRAR.
> 
> - The INVITE sent by alice has alice's public GRUU as Contact URI.
> 
> - bob sends some in-dialog request to alice (i.e. re-INVITE) which is
> routed based on Outbound rules (Outbound identifier in Route headers)
> by OB-2, PROXY/REGISTRAR and OB-1.
> 
> - Later OB-1 is restarted so the connection with alice is lost. At
> this point alice re-registers using some +sip.instance and reg-id. The
> REGISTRAR replaces its binding.
> 
> *** 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 sends a new in-dialog request to alice (i.e. BYE). When
> the request arrives to OB-1, that proxy will realize that the Outbound
> identifier belongs to an already closed connection so will reply 430
> "Flow Failed" to PROXY/REGISTRAR. And PROXY/REGISTRAR cannot perform
> "serial forking" since it's just an in-dialog request and therefore it
> SHOULD NOT examine the Request URI (which contains the public GRUU of
> alice).
> 
> 
> So, we have a hyper cool and complex specification/implementation of
> Outbound, Path and GRUU but still we cannot re-use an existing SIP
> dialog after a simple TCP disconnection? in 2012? Ouchhh.....
> 
> Hope I miss something. I'd appreciate any suggestion on this subject.
> 
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
      having the edge proxy add a Record-Route header with a flow token
      is one way to ensure that mid-dialog requests are routed over the
      correct flow.


Do we need a specification of this or is a solution just assumed?

/O


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to