Hi All,
I've tripped over a minor bug in the pjsua_acc_add_local function. I've
implemented a quick work around so I can continue my work but honestly I'm
not sure if it is the correct way to solve the problem so I'm hoping to get
some advice.
The bug occurs when running PJSUA on a system using two interfaces making
peer to peer calls. I'm using the console app as part of a testing
framework so I'm using a config file that contains:
--local-port=5060
--ip-addr=192.168.70.129
--rtp-port=5004
--no-tcp
--dis-codec=pcmu
--dis-codec=speex/8000
--dis-codec=speex/16000
--dis-codec=speex/32000
--dis-codec=ilbc
--dis-codec=gsm
--dis-codec=l16/44100/2
--add-codec=pcma
--auto-answer=200
--max-calls=1
--null-audio
--auto-play
--play-file=c:/near.wav
--auto-rec
--rec-file=c:/far.wav
--no-vad
--clock-rate=8000
--snd-clock-rate=8000
--quality=10
--ptime=40
--duration=5
As you can see, I specify that the app should use the
address 192.168.70.129, however when the SDP is generated for calls, I
found that PJSUA was populating the connection and media sections with the
other interfaces address (10.0.0.200).
I tracked it down to the function call pjsua_acc_add_local which uses the
default settings for pjsua_acc_config. This means the local account uses
any address and in my tests the wrong interface happens to come up first in
the list, so I get a malformed SDP.
My fix for this is to change the config struct to use the address of the
transport provided as a parameter like so:
Index: C:/dev/pjproject/pjsip/src/pjsua-lib/pjsua_acc.c
---=
--- C:/dev/pjproject/pjsip/src/pjsua-lib/pjsua_acc.c (revision 4166)
+++ C:/dev/pjproject/pjsip/src/pjsua-lib/pjsua_acc.c (working copy)
@@ -530,7 +530,11 @@
transport_param);
cfg.id = pj_str(uri);
- pj_strdup(pjsua_var.pool, &cfg.rtp_cfg.bound_addr, &t->local_name.host);
- pj_strdup(pjsua_var.pool, &cfg.rtp_cfg.public_addr, &t->local_name.host);
- cfg.rtp_cfg.port = t->local_name.port;
- return pjsua_acc_add(&cfg, is_default, p_acc_id);
}
I'm still pretty new to this code so I'm not sure if this is the correct
way to resolve this issue. Any guidance would be greatly appreciated.
Regards.
Pierre
--
**** Confidentiality statement and Disclaimer ***
This message and any attachments are confidential, intended solely for the
addresses and may contain legally privileged information. Any unauthorised
use or dissemination is prohibited. Electronic transmissions are likely to be
altered. Neither Faiveley Transport nor any of its subsidiaries or
affiliates shall be liable for the electronic transmission if altered,
changed or falsified.
If you are not one of the addressee(s) (or responsible for delivery of the
message to such person) you are not an intended recipient and you are
hereby notified that you may not read, use, copy or deliver the message to
anyone for any purpose. Instead you should destroy this message [alt.
delete this message from your system] and kindly notify the sender by reply
mail. Please observe that opinions, conclusions and other information in
this message not relating to the official business of my firm shall be
understood as neither given nor endorsed by it. Further, electronic
transmissions may be susceptible to data corruption, interception and
unauthorised amendment, and neither I nor my firm accept liability for any
such corruption, interception or amendment or the consequences thereof.
*** End of statement ****
Hi All,
I've tripped over a minor bug in the pjsua_acc_add_local function. I've
implemented a quick work around so I can continue my work but honestly I'm
not sure if it is the correct way to solve the problem so I'm hoping to get
some advice.
The bug occurs when running PJSUA on a system using two interfaces making
peer to peer calls. I'm using the console app as part of a testing
framework so I'm using a config file that contains:
--local-port=5060
--ip-addr=192.168.70.129
--rtp-port=5004
--no-tcp
--dis-codec=pcmu
--dis-codec=speex/8000
--dis-codec=speex/16000
--dis-codec=speex/32000
--dis-codec=ilbc
--dis-codec=gsm
--dis-codec=l16/44100/2
--add-codec=pcma
--auto-answer=200
--max-calls=1
--null-audio
--auto-play
--play-file=c:/near.wav
--auto-rec
--rec-file=c:/far.wav
--no-vad
--clock-rate=8000
--snd-clock-rate=8000
--quality=10
--ptime=40
--duration=5
As you can see, I specify that the app should use the
address 192.168.70.129, however when the SDP is generated for calls, I
found that PJSUA was populating the connection and media sections with the
other interfaces address (10.0.0.200).
I tracked it down to the function call pjsua_acc_add_local which uses the
default settings for pjsua_acc_config. This means the local account uses
any address and in my tests the wrong interface happens to come up first in
the list, so I get a malformed SDP.
My fix for this is to change the config struct to use the address of the
transport provided as a parameter like so:
Index: C:/dev/pjproject/pjsip/src/pjsua-lib/pjsua_acc.c
===================================================================
--- C:/dev/pjproject/pjsip/src/pjsua-lib/pjsua_acc.c (revision 4166)
+++ C:/dev/pjproject/pjsip/src/pjsua-lib/pjsua_acc.c (working copy)
@@ -530,7 +530,11 @@
transport_param);
cfg.id = pj_str(uri);
-
+
+ pj_strdup(pjsua_var.pool, &cfg.rtp_cfg.bound_addr, &t->local_name.host);
+ pj_strdup(pjsua_var.pool, &cfg.rtp_cfg.public_addr, &t->local_name.host);
+ cfg.rtp_cfg.port = t->local_name.port;
+
return pjsua_acc_add(&cfg, is_default, p_acc_id);
}
I'm still pretty new to this code so I'm not sure if this is the correct
way to resolve this issue. Any guidance would be greatly appreciated.
Regards.
Pierre
--
**** Confidentiality statement and Disclaimer ***
This message and any attachments are confidential, intended solely for the
addresses and may contain legally privileged information. Any unauthorised
use or dissemination is prohibited. Electronic transmissions are likely to *be
altered*. Neither Faiveley Transport nor any of its subsidiaries or
affiliates shall be liable for the electronic transmission if altered,
changed or falsified.
If you are not one of the addressee(s) (or responsible for delivery of the
message to such person) you are not an intended recipient and you are
hereby notified that you may not read, use, copy or deliver the message to
anyone for any purpose. Instead you should destroy this message [alt.
delete this message from your system] and kindly notify the sender by reply
mail. Please observe that opinions, conclusions and other information in
this message not relating to the official business of my firm shall be
understood as neither given nor endorsed by it. Further, electronic
transmissions may be susceptible to data corruption, interception and
unauthorised amendment, and neither I nor my firm accept liability for any
such corruption, interception or amendment or the consequences thereof.
*** End of statement ****