2008/9/8, Victor Pascual Ávila <[EMAIL PROTECTED]>:
> On Mon, Sep 8, 2008 at 3:23 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> > Anyway, it seems that SCTP offers some capabilities (IP redundancy in
> > a single connection) that SIP can't not advantage of them. Am I wrong?
> > This is: the transport layer knows about associations between IP:port
> > and connections, but just it, it doesn't know about complex SCTP
> > connections involving various IP's.
>
>
> Actually, in SCTP, an endpoint is represented as the tuple {IP1, IP2, IPn:
> port}
>
> IMO, the received parameter should only include the PRIMARY_PATH
> address and the SCTP failover should be used transparently.
Well, this could be easily solved if the SCTP socket used by the SIP
stack returns the PRIMARY_PATH as the IP:port. Then the SIP stack
would work just with that IP and the SCTP layer would handle the
connection and it's redundant addresses transparentely.
But for that, the SCTP socket in the SIP stack programming language
must return the PRIMARY_PATH even if the real used IP is different.
Is it feasible? I don't know SCTP protocol, neither a SCTP API in C or
other language, but if you have an object "SCTPSocket" with the
following behaviour then it should work ok:
- SCTP connection:
- local IP 1: 1.1.1.1 (PRIMARY)
- local IP 2: 1.1.1.2
- local port: 6666
- remote IP 1: 9.9.9.1 (PRIMARY)
- remote IP 2: 9.9.9.2
- remote port: 8765
- You receive a request in that connection in the address 1.1.1.2.
- You get a SCTP socket.
- my_sctp_socket.get_ip
=> 1.1.1.1
If the behaviour is this (getting the PRIMARY address *ALWAYS*) then I
think SIP should work perfectly over SCTP.
>
> > Isn't there really a RFC defining a new SIP transport layer model for
> > SCTP protocol?
>
>
> RFC4168: The Stream Control Transmission Protocol (SCTP) as a
> Transport for the Session Initiation Protocol (SIP)
>
> I'm afraid this document does not cover the above discussed issue.
Yes, very sad :(
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
