|
Le 02/10/13 10:15, Konrad Karl a
écrit :
Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too.Thanks for explanation, Damien! A question still remains for me: why is this done the way it is? If I e.g telnet some.ip.add.ress then routing rule apply and all traffic will go over the vpn interface (tun0 or such). When you are using telnet, there is an active TCP connection between both peers. When you are using Ekiga, you are working connectionless, ie through UDP. That means that userB can not use the same connection to reply back to you. All it can do is send a SIP message to a destination IP and port. If user B has two local interfaces (eth0: 192.x and tun: 10.x), when EkigaB will send a SIP message to userA, it will send it twice (because it can not determine how routing will work, that's the kernel responsibility) : - one SIP message to userA through tun0 with tun0 source IP address to userA IP and port - one SIP message to userA through eth0 with eth0 source IP address to user IP and port One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. The best would be that you post a -d4 output somewhere (not on the mailing list) of userB trying to reach userA so that we can determine what Ekiga is doing. Damien |
