Daha önce bildiğimiz gibi, ilk istekleri oluştururken arayan tarafından oluşturulan Via üstbilgisindeki bilgileri kullanarak arayana yanıtları geri göndeririz.
Bu tarz bir standarttır ve rfc3261’de tanımlanmıştır. Ancak gerçek hayatta, endpointler bir NAT’ın arkasında olduğunda, kendilerini genellikle özel adresleriyle (private IP adresiyle) tanımlayacaklardır ve bu durumda bahsettiğimiz standart ile kullanılmayacaktır çünkü localdeki bir adres ile haberleşmeye çalışacaktır.
Localdeki telefonumdan bir arama yaptığımda, telefonum kendisini oluşturduğu Via üstbilgisinde tanıtır ve yerel ağımdaki özel kimliklerini via header’da kullanır. Ancak bu durumda ağımın dışındaki bir sunucuya çağrı yapılmasını talep ettiğimde, bu URI’ye kesinlikle sunucu tarafından erişilemez. Bu nedenle, yanıtlar hiçbir zaman arayana düzgün şekilde geri dönmez.
Sorunu görüyor musunuz? Bu tür durumlarda received and rport devreye giriyor.
“Received” Via üstbilgisinde, paketin alındığı gerçek kaynak adresini içeren standart bir parametredir.Gerçek kaynak adresi derken; local değil modemin kullandığı public IP adresinden bahsediyoruz.
Via header’da IP adresi paketin geldiği kaynak adresinden farklıysa, “received” parametresi oluşturuyor.
“Rport” olarak adlandırılan yanıt bağlantı noktası aslında “received” parametresine benzer, ancak “rport” rfc3581’de tanımlanan bir IP adresi değil, bir port’tur.
UAC bir istek oluşturduğunda, Via header’da boş bir “rport” parametresi içerebilir.
Bir UAS bir istek aldığında, değer içermeyen “rport” parametresinin varlığını kontrol etmek için en üstteki Via başlığını inceler, eğer bir rport bilgisinde bir değer varsa, parametrenin değerini isteğin kaynak portu olarak ayarlar.
“Rport” parametresinin varlığı da “received” parametresi oluşturma kuralının üzerine yazar: UAS, Via üstbilgisinde belirtilen değerle aynı olsa bile, isteğin geldiği kaynak IP adresini içeren bir “received” parametre eklemelidir.
Şimdi bir örnek yapalım. Şimdi daha akıllı ve RFC3581’i destekleyen bir telefonum var. Arama yapıyorum istediği göndermeden önce Via başlığına boş bir “rport” parametresi ekliyorum.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.X.X:5060;branch=z9hK992054588;rport;
Benim public IP’min 100.0.0.1 olduğunu varsayalım, ayrıca rfc3581’i de destekliyor sunucum ve yanıta “rport” ve “alınan” parametresi ekliyor, 12345 NAT cihazımın sunucuya bağlantı oluşturmak için kullandığı kaynak port adresidir.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.X.X:5060;branch=z9hK992054588;rport=12345;received=100.0.0.1
Bu durumda sunucu, Via üstbilgisindeki (192.168.XX: 5060) URI’ye değil “rport” ve “received” parametresindeki konumlara, harici adresime ve harici bağlantı noktasına (100.0.0.1:12345) yanıt gönderir. NAT binding işleyen NAT cihazım yanıtları düzgün bir şekilde tekrar telefonuma iletir. “Geldiği yere geri gönderilir!”.
Fantastic !