2008/9/8, Victor Pascual Ávila <[EMAIL PROTECTED]>:
> Do you mean including the PRIMARY_PATH address in the ";received" even
> though the source address is a different one? This is actually
> possible (See Sockets API Extensions for Stream Control Transmission
> Protocol (SCTP) draft-ietf-tsvwg-sctpsocket-17.txt).
Yes, that's what I mean. Obviously is a hack, but RFC3261 is not ready
for things like SCTP (when considering the case of a single connection
involving various IP's in redundancy).
> I was considering this workaround but RFC3261 is still mandating: this
> (";received") parameter MUST contain *the source address from which
> the packet was received*.
>
> IMO, if RFC3261 is respected:
> - one-to-one style socket shall be used
> - when using sendmsg(), a preferred peer address shall be indicated if
> the sender wishes to discourage the stack from sending the message to
> the primary address of the receiver.
>
> Please, correct me if I'm wrong.
Well, I think that a hack must be done, maybe at SIP level or a socket level:
1) Hack at SIP level:
- Request received by ALTERNATIVE PATH.
- The function to get the origin IP must return the PRIMARY PATH so
SIP stack just knows about the PRIMARY PATH and uses it in "received".
- When sending a response, the SIP transport layer will receive
PRIMARY PATH as the destination and it's SCTP task to use the
ALTERNATIVE PATH since it's the "real" connection (I don't know how
SCTP handles it, but I expect it can done it easily).
2) Hack at socket level:
- Request received by ALTERNATIVE PATH.
- The function to get the origin IP must return the ALTERNATIVE PATH
so SIP stack uses it in "received".
- When sending a response, the SIP transport layer will receive
ALTERNATIVE PATH as the destination.
- A modified/new function will look for that IP in the SCTP tupples
and will find the existing connection so it will know both the PRIMARY
and ALTERNATIVE PATH and will use the appropiate one.
Interesting issue anyway ;)
> Cheers,
> --
>
> Victor Pascual Ávila
>
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors